Six Months Building Software for a Government Department: What I Didn't Expect

The project was a modernisation of a citizen-facing application portal, a system that members of the public used to apply for a particular government benefit. The existing system had been running since 2002. The goal was to rebuild it as a modern web application: better user experience, mobile-responsive, accessible, API-driven, deployable to cloud infrastructure.

I joined through a digital services contractor. The client team was a mix of civil servants who had worked in this department for decades and newly arrived digital specialists who had been brought in to run the modernisation. The tension between those two groups, not hostile, but present, shaped the project in ways I hadn't encountered in commercial software.

The Stability Reverence

The existing system had processed roughly 400,000 applications per year for 22 years. Its uptime record over that period was, by any measure, remarkable. The civil servants who had operated it knew its failure modes by heart, had runbooks for every scenario, and had accumulated 22 years of institutional knowledge about edge cases in the application process, cases that reflected real-world complexity in the eligibility rules, cases that would only appear in a new system if someone had thought to include them explicitly.

Coming from commercial software, I was accustomed to treating the existing system as the problem and the new system as the solution. In this context, that framing was wrong. The existing system was not primarily a source of technical debt to be replaced, it was a body of embedded knowledge about how the application process actually worked, accumulated over two decades of real-world operation. Every quirk in the old system's behaviour was either a documented rule or an undocumented accommodation for a real edge case that someone had encountered at some point and handled.

When we found something in the old system that seemed wrong or unnecessary, the correct response, which I learned slowly, and not always gracefully, was to find the civil servant who had been there longest and ask why it worked that way. The answer was usually "because in 2009 we had a case where X happened and this was the fix," and the fix had been forgotten but the code had survived. We preserved several "unnecessary" behaviours in the new system after discovering that they handled real cases that still arrived, just rarely enough that the new development team hadn't seen them.

Procurement and the Constraint on Dependencies

Government procurement rules in the UK (and in most national contexts I've seen described) constrain what software, infrastructure, and services can be used in public sector projects. This is not bureaucratic obstruction, it is a response to real historical problems with vendor lock-in, data sovereignty, and the security vulnerabilities that come from dependencies on commercial services whose terms of service can change at any time.

The practical effect on development was significant. Several libraries and services we would have used in a commercial context were not on the approved list. The approved cloud infrastructure had more constraints than we were used to. The deployment pipeline had to go through a security review process at every major change, which added time to each release. Using a third party analytics service required a data processing agreement and a data protection impact assessment, which were not optional and which took time to prepare and get signed off.

I found this frustrating at first. Over time, I came to understand it as a different kind of engineering constraint, one that required thinking more carefully about the services we depended on, the data they processed, and the implications of those dependencies at a level that I hadn't been asked to think about in previous jobs. A commercial startup can take on a dependency without much process. A government system serving a million citizens per year has to think about what happens if that dependency disappears, or changes its privacy terms, or becomes unaffordable, or is acquired by a company with different data practices.

Accessibility as a Non-Negotiable Requirement

The Web Content Accessibility Guidelines (WCAG) 2.1 Level AA compliance is a legal requirement for government digital services in most jurisdictions. This is not a nice-to-have. It means that every component, every interaction, every form, every error message, every piece of content has to be tested with assistive technologies, screen readers, keyboard-only navigation, high-contrast mode, and corrected until it passes.

The reason this requirement matters more in a government context than a typical commercial one: citizens cannot choose not to use government services. A commercial service that is inaccessible loses some users and retains others. A government benefit application portal that is inaccessible may be the only available route for people who need that benefit. The inaccessibility is not a business problem, it is a legal and moral failure of service delivery.

Building to WCAG AA is not complicated if you start with it. It is very expensive to retrofit it afterward. On this project, the accessibility requirements were treated as a core constraint from the beginning, every component was tested with a screen reader before it was marked as done, every form was validated with keyboard-only navigation before it was reviewed. This slowed individual features down by maybe 20%. It prevented a large and expensive remediation effort later in the project, which had happened on a previous phase and consumed most of the project's contingency budget.

The Definition of "Done"

In commercial software, a feature is usually "done" when it passes QA and code review, deploys successfully, and meets the acceptance criteria. In government software, there were additional checks that took time and weren't negotiable: security review, accessibility audit, user research validation (real users testing the feature with researchers observing), content review by the policy team to ensure the language complied with plain English guidelines and accurately reflected the current policy, and sign-off from the information governance team on any new data fields.

Each of these added time. The total cycle time from "feature spec agreed" to "feature in production" was longer than on any commercial project I had worked on. But the rate of post-release issues was correspondingly lower, and the features that reached users were better understood and better calibrated to what users actually needed, because the research had been done before release rather than after.

I think about this now when I hear "move fast and break things" as a development philosophy. There are contexts where it is appropriate. Public sector services that millions of people depend on, where the cost of a broken thing falls on some of the most vulnerable people in the population, are not those contexts. The process is slower because the cost of getting it wrong is higher. The correlation between those two facts is not accidental.

What I Took Away

Six months in government digital services taught me that the constraints that make commercial developers impatient, procurement rules, accessibility requirements, security reviews, research cycles, are not bureaucratic overhead. They are the engineering environment in a context where correctness, inclusivity, and security have a different weight than they do when the worst consequence of a bug is a frustrated paying customer.

The civil servants I worked alongside had a relationship with their users that was fundamentally different from anything I had experienced. Their users were not choosing to use the service. In many cases, the users were applying for something they urgently needed, financial support, a licence, an entitlement. The responsibility the civil servants felt toward those users was genuine and visible in how they approached every design decision. That culture of responsibility was a better reason to do accessibility testing carefully than any WCAG checkbox.

I came out with much more patience for process and much more respect for institutional knowledge. I also came out with the habit of asking "who is worst served if this doesn't work?" about every feature I build. In commercial software the answer is usually "nobody catastrophically." In public sector software the answer is sometimes "the people who can least afford it."