County revenue portals and citizen services fail for predictable reasons. Nearly all of them are decided before a line of code is written.
Public sector digital projects have a reputation, and it is not entirely undeserved. A portal launches, gets announced, and eighteen months later the counter downstairs is still processing most of the volume on paper.
The failures are rarely mysterious. They repeat, and they are almost always decided in the first few weeks — in scoping, procurement and process decisions — rather than in the build.
The service has to be better than the queue
A citizen choosing between an online form and a physical counter is making a rational comparison. If the online route takes four screens, requires a document they must scan, times out on a slow connection, and still ends with "bring the printout to the office", the queue wins. It should.
The benchmark is not "does the digital service exist". It is is this demonstrably faster and more certain than the alternative. That usually means:
- The transaction genuinely completes online, with no physical follow-up step.
- The citizen receives proof immediately, in a form they can present later.
- The process works on a low-end phone over an unreliable connection.
- Failure states are explicit — a clear "this did not go through" beats a spinner that resolves into ambiguity.
If any of those is missing, adoption stalls, and the usual response is to mandate the digital channel rather than fix it. That converts a service problem into a public frustration problem.
Payment reconciliation decides credibility
For revenue services — parking, permits, licences, land rates — the technical core is reconciliation, and it is where trust is won or lost.
A citizen who pays and does not receive a receipt will assume the money is gone. A county that cannot match a mobile money payment to an assessment cannot answer them. Both problems stem from the same source: treating the payment gateway as the record rather than keeping an independent ledger.
The pattern that works is the same one that works in banking. Record the obligation before payment is attempted. Record every gateway interaction with enough context to reconstruct it. Match continuously. Make unmatched payments visible to staff who can act on them the same day, not at month end.
Legacy systems are the constraint, not the enemy
Most counties and agencies already run something — a register, a billing system, occasionally a database nobody has documented. The instinct to replace it wholesale is understandable and usually a mistake, because the old system encodes years of rules that were never written down anywhere else.
The lower-risk route is to put a well-defined interface in front of the existing system, move one service at a time, and keep both paths running until the new one demonstrably carries the volume. Slower to announce. Considerably more likely to still be working in three years.
Procurement shapes architecture more than architects do
This is the part rarely discussed openly. A contract that specifies deliverables as a fixed list of screens will produce a fixed list of screens, whether or not they turn out to be the right ones. A contract with no provision for the discovery work — sitting with the clerks, learning what the process actually is as opposed to what the manual says — will produce a system built on an inaccurate model of the work.
The most valuable thing a procuring entity can do is fund a short discovery phase as separate, deliverable work before committing to a full scope. It costs a fraction of the build and routinely changes what gets built.
Accessibility and language are not extras
A public service is for everyone, including people using an old handset, a screen reader, or a second language. In practice this means readable contrast, labelled form fields, sensible tap targets, plain wording, and a page that functions when the JavaScript has not finished loading.
These are cheap when designed in and expensive to retrofit. They are also, for a public body, closer to an obligation than a preference.
What we look for
When we assess a public sector system, the questions are consistent:
- Can a citizen complete the whole transaction without a physical step?
- Does the entity hold an independent record of every payment?
- Is there a documented rollback if the new path fails?
- Can staff resolve an individual case without a developer?
- Does it work on a cheap phone over a poor connection?
A system that answers yes to all five is unusual, and it will be used.
Where we fit
We build county revenue systems, citizen service portals, permit and licensing workflows, and integrations with existing registries. Most of the work is incremental — putting a reliable interface on systems that already hold the data and making the reconciliation trustworthy.
See our government and public sector page for detail, or describe what you need.