Software Development for Special Districts & Joint Powers Authorities
Software Development for Special Districts and Joint Powers Authorities
Small, supportable applications, integrations, and accessible public services for districts and authorities that have no developers on staff.
Special districts and joint powers authorities buy almost all of their software and write almost none of it. A fire district runs records and incident reporting software built for fire districts. A water district runs utility billing on one platform and treatment control systems on another. A park district runs recreation registration, a library district runs an integrated library system, a healthcare district runs a clinical system its medical staff chose. Very few of these agencies employ a developer, and many do not employ IT staff at all. When development work is needed, it is needed in the gaps: the application residents still submit as an email attachment, the billing data the vendor will not push into the finance system, the inspection log that lives in a spreadsheet on one retiring employee's desktop.
The risk here is not so much a failed project as an unsupportable one. An agency with a few dozen employees and a service provider that does not write code can end up holding custom software nobody can change. Anything built for a district has to be small enough to justify to a board, documented well enough to hand to the next person, and inexpensive enough to keep running out of a budget funded by rates, assessments, or member contributions.
What these environments look like
- A cloud productivity platform, usually Microsoft 365 or Google Workspace, plus a short list of mission systems: fire records and incident reporting, utility billing, recreation registration, library circulation, or a clinical system
- Vendor-hosted applications where the district has no database access, so integration means whatever API, scheduled export, or file drop the vendor is willing to support
- A public website carrying agendas, board packets, minutes, rate and assessment notices, and service forms, maintained by a communications staffer or an outside web firm rather than by IT
- Real processes running on spreadsheets, shared inboxes, and the occasional legacy desktop database: backflow test tracking, hydrant inspections, facility reservations, will-serve letters, claims intake, volunteer records
- A managed service provider responsible for support, network, and devices, with no application development capability and no ownership of business processes
- For joint powers authorities, data arriving from member agencies in inconsistent formats on inconsistent schedules, and reporting obligations back to each member's board
- GIS maintained by an engineer or a consulting firm, often the only authoritative record of where the district's assets are
Where HQT helps
- Small applications built on platforms the district already licenses, including the low-code tooling bundled with a cloud productivity subscription, so the ongoing cost is a license the agency already pays for
- Public-facing services for applications, payments, program registration, service requests, and status lookup, designed for a phone and built to the Web Content Accessibility Guidelines at the AA conformance level
- Integration between vendor-hosted systems and finance, billing, and reporting, using documented APIs or agreed file exchanges, with monitoring so a failed transfer is noticed by staff rather than by a customer
- Intake and reporting for joint powers authorities that validates member agency submissions when they arrive instead of reconciling them by hand at the end of a quarter
- Replacement of spreadsheet and desktop database processes with tracked, auditable applications, starting by documenting the business rules those files carry, which is usually the most valuable part of the work
- Accessibility review and remediation of websites, online forms, and the document libraries where board packets and public notices accumulate, an area under more scrutiny since the United States Department of Justice adopted a technical accessibility standard for state and local government web content and mobile applications, with compliance dates that vary by entity
- Modernization of an application a district commissioned years ago and can no longer maintain, and ongoing support with defined response times, source code in a repository the district owns, and documentation written for whoever inherits it
How an engagement usually starts
The trigger is usually a process rather than a technology. A general manager notices that staff spend several days a month assembling a report by hand. A vendor answers a feature request by saying it is not on the roadmap. A board member cannot use an online form on a phone, or an accessibility complaint arrives. A system replacement finishes and leaves an obvious gap where two platforms used to meet. In joint powers authorities, it is often a member agency asking for numbers the authority cannot produce quickly.
Work of this kind normally begins with a short discovery effort rather than a development contract: sitting with the people who run the process, reading the vendor agreement and whatever API documentation exists, and establishing whether the right answer is to configure something the district already owns, buy a product, or build a small application. That produces a written recommendation and a fixed-price scope sized to fit the district's purchasing authority or a single board agenda item. Delivery then runs in short increments staff can see working, with support and handover settled before the first line of code is written.