Water utility software

// The problem

A water and wastewater utility posts bills by mail, takes payments by cheque and at the counter, and announces boil-water notices and shutoffs by phone and social media, so customers call to ask what is happening.

// What we would build

A customer portal on the utility's own brand where customers see their usage and bills, pay online and sign up for notices by email or text, with an outage and notice map from the utility's GIS. Bills and accounts are read from the billing system through its API; we check yours before we quote. Notice wording is set by the people responsible for it at your utility.

// What is in it

// Stack

• Next.js
• PostgreSQL
• Billing system API
• ArcGIS REST API
• Payment processor's hosted checkout
• AWS Canada

// The problem

A regional water board bills from an Access database with macros written by a former employee, meter readers key reads from paper, and a change to the rate table means a week of testing on a copy of the file.

// What we would build

An architecture review of the old system first, with a written plan, then a new billing system that keeps every account, rate and history, an Android app meter readers use offline on their route, and bill runs checked against the old system before the switch. Ledger postings go to QuickBooks Online, built on its API.

// What is in it

// Stack

• Next.js
• Kotlin for Android
• PostgreSQL
• QuickBooks Online API
• AWS Canada

// The problem

A utility's operators see SCADA only in the control room, lab results live in spreadsheets, and the monthly report data and the council's dashboard are assembled by hand from both.

// What we would build

A data warehouse that reads SCADA historian data through a read-only connection, takes in lab results and billing consumption, and shows dashboards for operators, managers and council. It prepares report data for your responsible operator to review and submit. Nothing is ever written back to SCADA or any control system.

// What is in it

// Stack

• PostgreSQL
• dbt
• Historian API (read-only)
• Next.js
• Apache Superset
• AWS Canada

// The problem

Crews take work orders on paper, pump station checks live in a binder, and the lead service line inventory the utility must keep is a spreadsheet with gaps for half the addresses.

// What we would build

A web workspace and an iOS and Android app crews use offline, on the utility's GIS and asset register: work orders for mains, valves, hydrants and pumps, station rounds, and a service line inventory with the material recorded at each address, how it was found, and photos. A public lookup shows a resident what is known about their line.

// What is in it

// Stack

• Next.js
• React Native
• PostgreSQL with PostGIS
• ArcGIS REST API
• AWS Canada

// The problem

A multi-utility billing water, sewer and district energy runs a billing system, a meter data head-end, GIS, a work order system and finance software that do not talk, so staff export and import files every night.

// What we would build

An internal integration hub that joins the five systems through one API: meter reads flow to billing, new accounts reach the work order system, and service addresses stay in step with GIS. Each connector is built on the system's published API or export; we check yours before we quote. We run it for you, with monitoring and alerts.

// What is in it

// Stack

• Node.js
• PostgreSQL
• OpenAPI
• Billing and meter data APIs
• ArcGIS REST API
• AWS Canada

// The problem

A city utility serves customers who speak many languages, its help pages exist only in English, and the call centre fills up with the same questions about bills, moving and water quality notices.

// What we would build

A help centre in English, French and the languages your customers speak, with an assistant that answers from the approved articles, cites them and hands over to a person. Active notices are shown first. The assistant answers general questions; it does not see accounts, and it never gives health or safety advice beyond the notice itself.

// What is in it

// Stack

• Next.js
• Claude API
• PostgreSQL with pgvector
• Translation management platform
• AWS Canada

// The problem

Several towns buy treated water from one regional plant, the bulk meter readings and cost shares are worked out in a spreadsheet the plant keeps, and each town checks it its own way.

// What we would build

A shared record where bulk meter readings, capital and operating costs and each member's share are entered and agreed each month, on a private permissioned ledger each member runs a node of. Signed monthly statements often do this job; the ledger helps when several members need the same record and none wants another to hold it.

// What is in it

// Stack

• Next.js
• Hyperledger Besu (private, permissioned)
• PostgreSQL
• AWS Canada