Software Development for Water, Power & Public Utilities
Software Development for Water, Power, and Public Utilities
Portals, integrations, and legacy modernization around utility billing, metering, and asset systems, with a firm boundary at control systems.
A publicly owned utility is judged on two things that have little to do with each other: whether the water is safe and the power stays on, and whether the bill is right. The first depends on control systems that operations staff protect from casual change. The second depends on a customer information system, a metering platform, and a payment path that customers compare, without being asked to, against every bank and phone company they pay online.
Development work at a utility lives in the space between those worlds. It is rarely a request to replace the billing system, and almost never a request to write anything that runs a plant. It is the self-service portal the customer information system does not include, the interface that moves meter reads into billing without a nightly file somebody re-runs by hand, the service line inventory the state is asking for in a form no current system produces, the mobile form that replaced a clipboard. Each of these touches a system of record that cannot be disrupted, and each ends in a bill, a work order, or a regulatory report.
What these environments look like
- A customer information and billing system, sometimes a module inside the city or district ERP and sometimes a standalone product, carrying rate rules layered on every time the governing board adopted a new rate structure
- Advanced metering infrastructure with a head end or meter data management system producing interval reads, of which billing consumes only a daily or monthly summary
- SCADA, historians, and control systems at plants, pump stations, and substations, under change control that operations owns, and in electric utilities that own bulk system assets, under reliability standards with their own compliance evidence
- GIS as the authoritative record of mains, service points, meters, and premises, usually not synchronized with what billing believes about the same addresses
- Asset management and work order systems used by crews who work in places with unreliable cellular coverage
- Payment channels spread across a web portal, an interactive voice response line, kiosks, and a lockbox, each integrated separately and each inside the scope of payment card security requirements
- Customer-facing sites and notices subject to state and local government accessibility obligations, including the Department of Justice rule that adopts a WCAG conformance level for web content and mobile applications, with compliance dates that depend on the size and type of the entity
Where HQT helps
- Customer-facing portals for starting and stopping service, viewing usage, paying bills, setting up arrangements, and reporting leaks or outages, built to WCAG 2.1 Level AA and designed for a phone first
- Integration between metering, billing, GIS, asset management, and outage systems through documented APIs and monitored interfaces, replacing file transfers that fail quietly overnight
- Legacy modernization of billing adjuncts and service applications a utility built years ago, beginning with extraction of the rate, proration, and service rules that exist only in that code
- Applications behind regulatory deliverables that are still assembled by hand, including service line inventory records and the customer notification tracking that federal drinking water rules have made a recurring obligation
- Low-code applications on platforms the utility already licenses, for cross-connection and backflow test tracking, will-serve letters, hydrant meter permits, locate ticket handling, and customer assistance program intake
- Mobile and offline-capable field tools for meter exchanges, inspections, and condition assessment that sync when the crew returns to coverage
- Application support with defined service levels and release discipline, so that a billing change does not reach production during the week bills are generated
How an engagement usually starts
The trigger is usually a date or a dispute. A metering deployment finishes and the data arrives with nothing downstream using it. A regulator or a state agency asks for an inventory or a notification record that the utility can only produce by hand. A rate change is adopted and the billing system cannot express it without a workaround the finance director does not trust. Or the customer service supervisor brings in a month of complaints about a portal that does not work on a phone.
The first step in work of this kind is a short discovery: reading the interfaces and the code that already exist, sitting with the billing clerks and field supervisors who run the process today, and settling which system is the record for premises, meters, and service points, because that answer drives most of the design that follows. Discovery produces a written scope and a fixed-price proposal for a first increment small enough to fund from an operating budget or fold into a capital project, and sized so that something works before the next board meeting rather than at the end of a long build. HQT does not make changes to control systems. Where a project touches operational technology, we define the boundary in writing and work through the utility's integrator and operations staff.