How to Build Government Software That Taxpayers Actually Like

Five rules for how to pull off software projects that bring staffers emotional relief and make constituents feel genuinely surprised at how functional their government is.

Here’s the rub: the average person who votes and pays taxes judges their government based on what’s tangible to them. They notice whether potholes are being filled, whether life is getting more affordable, and whether accessing public services feels like going to an unusually hostile dentist. And underneath all these perceptions is one constant: software. 

Every policy has to be implemented, and almost every leg of actual service delivery runs through software. A government with bloated, inflexible, and outdated digital infrastructure simply isn’t going to deliver good services, even if the end services aren’t themselves digital. And having good software is in the control of every agency at every level. 

The bad news

Most government software is old and bad, from core federal agencies to local school boards. America has a second and far less discussed national deficit: trillions in collective technical debt.

While constituents don’t always think of this technical debt as a root problem, they feel its effects deeply. They can go to a Chick-fil-A and get reliably pleasant and painless service for a few dollars. But when they try to claim benefits or file their taxes, it’s far less clear that paying their taxes is getting them a good deal.

The good news

Some government software is good now. There’s been an ongoing renovation project [link], not just to major services and websites, but to how governments think about buying and developing software. 

One of the pioneers in this movement was the UK Government Digital Service, which came up with a list of core design principles back in 2012. While we take this list as a still-shining north star, what follows is a partial adaptation that accounts for how the world has changed since. The development tools available today are far more powerful than in 2012, and the sense of urgency in digital services reform much stronger. 

The 5 rules 

The end goal of all these rules is ensuring digital services are highly auditable, interoperable, future-flexible, and secure. But more fundamentally they should also just be pleasant and easy to use—for government employees and constituents alike. 

1. Start with users, not requirements

The worst way to build software is top-down. To paraphrase Mike Tyson, everyone has a plan until they get punched in the face by what users actually want. The more time spent sculpting requirements in a boardroom, the less flexible you’ll be to real-world usage.

When structuring an RFP, start with user research as its own project. This will allow you to rebuild your requirements around the elements that really matter before committing time and capital to a system that might severely disappoint. 

How can this be done within traditional RFP processes?

2. Demand that vendors recommend improvements

While judging proposals typically comes down to answer quality, legible expertise, and overall price, there are better tests that can help you uncover which contractors are best aligned to your interests. Like the magic question: which of these suggested requirements do you think is likely to lead to a bad product?

Many vendors just want the award, and don’t have a business model that allows them to recommend adjustments likely to shrink the total dollars on offer. They may also simply not know the answer, nor wish to be held responsible for the risks that comes with new approaches. So if you don’t ask them this question, they’re unlikely to volunteer this kind of feedback. But if you don’t, you end up with concrete boats.

Which vendor business models do allow for helpful candor?

3. Hire leaner teams with better tools

In the words of the founder of the UK’s Government Digital Service:

The harsh truth for governments all over the world is that many digital public services could be developed at a fraction of the size by very small teams. 

The best private software companies are increasingly moving in this direction. As the breadth and quality of available tools has grown—especially with recent AI advancements—even a single strong engineer can produce more and better work today than what a small team could a decade ago. And this effect will only continue to compound.

It’s not just about per-hour efficiency either. It’s what those hours are being used to do. Leaner teams come with substantially lower coordination costs. Less time is wasted on syncs and meetings, and more of each dollar spent goes to actual development. 

Aren’t AI tools still unreliable? Doesn’t it just produce faster but worse code?

4. Ensure minimum talent bars

Jennifer Pahlka was recruited to help kickstart the US Digital Service in the aftermath of the healthcare.gov disaster. Her subsequent book/manifesto, Recoding America, included a sort of microcosmic anecdote:

The requested change was there, just as directed—but preceded by two forward slashes. This designated a comment, essentially a note programmers leave for the next programmer who’ll come along. The slashes told the computer not to read that line as code but to ignore it. Why did the contractor do that? “I saw other lines had these slashes so I thought I should put them in too,” he explained. This supposedly technical staff member had never written a line of code.

While not every vendor is guilty of this excess, the bar has always been uneven. It takes technical talent to judge technical talent, leaving many procurement officers at a structural disadvantage. While they can review CVs for some minimum of legible experience, this won’t necessarily tell them whom on the team is familiar with modern tools and best practices, nor just how much code is being written by those lowest down the talent ladder.

Zooming in further, it's also important to ask vendors about their subcontracting practices. The talent of their core team is an aside if much of the actual work is being farmed out. One major tell: who owns the performance reviews for those writing the bulk of the code? Are those being delegated too? While subcontracting isn't necessarily bad in itself, you need to make sure that the prime contractor's culture and standards extend all the way.

As the old adage goes: If you think hiring a professional is expensive, try hiring an amateur. Bad work, at best, is caught early enough to only lead to delays and overruns. At worst, it introduces fragility that only becomes clear long after cheap fixes are no longer available.

How does GovTron approach this problem?

5. Hire product managers, not project managers

A bad model of contracting is a vendor checking in periodically to say “yes, what you asked for is still being built, here’s the latest”. While this is better than no progress being made, this isn’t what leads to outcomes that anyone will be proud of. 

What defines a product manager is their felt strength of ownership over the usability of what their team ships, and how competent and empowered they are to step in when development is no longer aligned. They don’t just coordinate schedules and updates; their job is to constantly ask the right questions to make sure the right work is being done.

You can read more about the product vs. project manager distinction in our companion guide. But the upshot is simple: while you want a point of contact that stays on top of emails and Jira tickets, one who knows which tickets should exist will deliver far better software.

Does GovTron offer product managers for all contracts?