Why government apps fail before engineering does
Most civic products lose at the behavior layer, not the codebase.
I've watched government teams spend months (sometimes years) building mobile apps that citizens download once and never open again. The post-mortem always starts in the wrong place.
Engineering gets blamed. Or procurement. Or App Store policy. Sometimes all three. But when I sit with the teams and walk through what actually happened, the failure usually occurred earlier. Before the first line of code. Before the RFP. Sometimes before anyone asked a simple question: Why would a person come back to this?
The requirements trap
Government apps are often designed around requirements documents. Stakeholders list what the app must do. Vendors build to spec. Everyone signs off. The app launches.
Nobody asked what behavior the app is trying to create.
Requirements describe features. They rarely describe habits. They don't account for the fact that a citizen downloading your parking app at 8 AM on a Tuesday is not in the same mental state as your QA team testing feature #47 in a staging environment.
I've seen apps with flawless WCAG compliance and clean architecture that still fail, because they ask citizens to learn a new mental model for a task they perform twice a year. The engineering works. The behavior doesn't.
Trust is a product feature
In the private sector, a confusing app costs you a customer. In the public sector, it costs you something harder to measure: institutional trust.
Citizens don't distinguish between "the app crashed" and "the government doesn't work." To them, it's the same thing wearing different clothes. One bad experience with a DMV app doesn't just lose that session, it poisons the next ten interactions across every digital channel you operate.
This is why simplicity creates trust. Not simplicity as aesthetic preference. Simplicity as respect for the person's time, attention, and anxiety. Government apps often serve people in stressful moments: paying a fine, checking benefits, reporting an issue. Every unnecessary tap reads as indifference.
Adoption is not distribution
Teams celebrate launch day download numbers. Then retention collapses by week two.
Downloads measure curiosity. Retention measures value. Most government apps optimize for the first and ignore the second, because launch metrics are what procurement celebrates and retention metrics are what product teams lose sleep over.
The apps that work (the ones citizens actually use) share a pattern I've seen across state lotteries, county services, and civic tools:
- They do one thing clearly, not ten things adequately.
- They meet people where they already are (text alerts, existing workflows, familiar patterns).
- They earn the next visit by delivering value on the first one.
- They feel stable before they feel feature-rich.
That last point matters more than most teams admit. I wrote about it in Stability before growth, the instinct to add features before fixing the experience that makes people leave.
What I'd do differently
If I were advising a government team starting a mobile product today, I'd push for three things before anyone opens Xcode or Android Studio:
- Define the behavior, not the feature list. What should a citizen do differently after using this app? How often? What triggers them to return?
- Map the anxiety. What is this person worried about when they open the app? Design for that emotional state, not the happy path in your user story.
- Ship small, measure retention, then expand. The worst government apps are the ones that try to digitize an entire department in version 1.0.
Engineering matters. Accessibility matters. Security matters. But if you solve all of those and nobody comes back, you've built expensive infrastructure for a behavior that never formed.
Technology is the medium. Behavior is the outcome.
Government technology fails when teams forget that order. They build the medium and hope the outcome follows. It rarely does.
I'm still learning this myself, in lottery apps, civic tools, and the family business I operate. The pattern holds everywhere I've looked: the product problem is almost always a behavior problem wearing a technical costume.