Photo: Google Gemini · AI-generated
Most business software gets to assume things about its users. They were trained on the system. They use it daily, so yesterday’s quirks are today’s muscle memory. If something breaks, they file a ticket and work around it, because using the software is part of their job.
Public-sector software gets to assume none of that. The user is a resident who opens the app once a year to pay a traffic fine, renew a licence, or find a safe cycling route — and who never received training, never will, and owes the software no patience at all. That single difference cascades into every engineering decision, and it’s why govtech that merely “works” by internal-tool standards routinely fails in the field.
The user you must design for is the one you’ll never meet
An internal tool serves a known population: a few hundred employees, known devices, known context. A citizen-facing service serves whoever shows up — every age group, every level of digital confidence, old low-end Android phones alongside this year’s iPhone, impatient people in a queue and anxious people facing a fine. When we built PayCity, which lets residents of South African cities view and pay traffic fines from their phone, the core product decision wasn’t a feature — it was ruthlessness about friction. A resident confronting an unexpected fine is not in the mood to fight a UI. Every screen had to answer exactly one question (what is this fine, what do I owe, how do I pay), because for this user there is no second session. Either it works the first time, or they’re back in the queue at a municipal office — and the software has failed at the one thing it existed to remove.
Trust is a feature you can’t retrofit
A citizen paying money to a government system brings a different kind of scrutiny than an employee logging their hours. If the amount looks wrong, if the payment hangs, if the confirmation never arrives — the user doesn’t file a bug report; they stop trusting the channel, tell other people to stop trusting it, and revert to standing in line. That trust burden lands hardest on the data layer. PayCity’s real engineering was the integration layer normalising fines data from multiple local authorities’ back-office systems into one consistent, accurate view — because a fine displayed with the wrong amount even once does more damage than a crash. CarLicence makes the same point at platform scale: it turns South Africa’s licence disc renewal into a real-time API that businesses embed in their own websites, apps, and even ATMs. Every downstream partner is lending their brand to that renewal flow. The API being fast and reliable isn’t a service-level nicety — it’s the entire business model, held up by unglamorous engineering: cloud automation that keeps renewal status current without manual intervention, and monitoring that catches degradation before a partner’s customer does.
Public goals, production standards
Public-sector software also carries policy weight that commercial software doesn’t. The City Cycling Navigation App we delivered for a German state capital exists to serve a measurable civic target — growing cycling’s share of city traffic toward 25% as part of a 2035 climate-neutrality strategy. Software in that role isn’t judged by downloads; it’s judged by whether residents quietly change behaviour because the tool made the better option easier. That only happens if the app clears the same bar as the best consumer apps on the user’s phone — because that’s what it sits next to. “Good for a government app” is not a standard citizens accept, and it shouldn’t be one delivery partners accept either.
What this asks of a delivery partner
None of this requires exotic technology. It requires taking seriously that the public is the hardest user base there is: untrained, diverse, time-poor, and entitled — correctly — to services that just work. Practically, that means native quality on both mobile platforms where the audience lives, integration layers that make fragmented government back-office data look coherent, infrastructure sized for spikes (fines and renewals are deadline-driven — load arrives in waves), and the discipline to keep all of it boring and dependable for years. That’s custom software work with the volume turned up on reliability, and it’s some of the most consequential work we do — because when it’s done right, the reward is that nobody notices it at all. If you’re building for citizens — directly, or as the agency holding the client relationship — we should talk.