Perspective

We built a government service prototype in 15 minutes. Here's what that could change.

AI has all but removed the cost of building a first version of software. It’s a bit like the arrival of digital photography: suddenly you could take a thousand shots for the price of one. I’ve written about that parallel before.

The real opportunity isn't simply to produce more, it's to get better at deciding what to create, what to test and what to discard.

At the Central Government Partnership Network (CGPN), my colleague Rumman Amin and I decided to put that idea to the test. We gave ourselves 15 minutes to build a working government service prototype, live in front of an audience.

What we built

Our challenge was to create a service that could help someone find out information about their home, including an estimate of when it was built.

While Rumman talked through the implications of AI for government service delivery, I set several AI agents working in parallel.

I started with Claude Design, using the GOV.UK Design System to generate a proposed service journey and interface.

Alongside that, I set a front-end development agent working with Claude Code and the GOV.UK Prototype Kit.

A separate back-end agent tackled the underlying logic, including connecting to property-related data sources such as GOV.UK's Energy Performance service and ONS address data.

The idea was to have the different agents working on parts of the problem simultaneously, rather than treating design, front-end development and back-end integration as entirely sequential activities.

We started with a fresh account and no prebuilt service.

By the end of the session, we had a working website that could take information from a user and return an estimated age for their property.

It wasn't perfect, there were adjustments along the way, and we certainly hadn't created a production-ready government service. But we'd gone from a brief to something tangible, which people could interact with, in a quarter of an hour.

The bigger question: why do we still work the way we do?

Government's established Discovery, Alpha, Beta and Live approach was developed in a world where building and changing software was relatively expensive.

It made sense to invest significant time in reducing uncertainty before committing to development.

That underlying principle remains sound, but what happens when the cost of exploring an idea through working software falls dramatically? If a prototype takes minutes or hours rather than weeks to create, we can afford to explore more alternatives before deciding which one deserves investment, and importantly we can afford to throw more of them away.

That's not a failure, it's how we learn.

Perhaps an Alpha doesn't need to continue for a predetermined number of weeks if we've already gathered the evidence needed to make a decision. Perhaps we can test several different approaches with users rather than investing heavily in just one. Or maybe we can reduce some of the waiting time between phases by keeping a team together and giving them the tools to move more quickly.

This isn't about abandoning good delivery practices. It's to question which parts of our processes still serve their original purpose, and which assumptions have changed.

Faster software doesn't mean easier government delivery

There's an important distinction here. AI can accelerate the creation of interfaces, prototype journeys, boilerplate code and early technical experiments.

It cannot remove the need to understand the people who will use a service, navigate policy constraints, work with other organisations, integrate with complex legacy systems or earn users' trust.

Nor does generating code quickly make that code automatically secure, accessible, maintainable or suitable for production.

One audience member asked about accessibility. Another wanted to understand token usage and the costs of running these tools at scale.

Those were exactly the right questions. For context, the demonstration used approximately 2% of the weekly allowance on the Claude subscription I was using. That's encouraging for the economics of experimentation, but it isn't a meaningful estimate of the total cost of delivering or maintaining a government service.

The engineering, governance and operational responsibilities don't disappear just because the first version can be produced quickly.

The exciting possibility is that we can spend less time creating something to test, and more time on the difficult work of making sure it's the right thing.

So what should we do differently?

I think there are three practical opportunities for government teams.

Test more ideas, earlier. If creating a working prototype becomes much cheaper, we should use that advantage to explore different approaches and put them in front of users sooner.
Make decisions based on evidence, not elapsed time. Rather than treating the length of a delivery phase as fixed, be clear about what needs to be learned and make the next decision when the evidence supports it.
Rethink how teams move from exploration into delivery. If we can shorten some of the technical work, we should also examine the handovers, approvals and gaps between phases that can slow progress.

None of this means removing the safeguards that matter in public services. It means making better use of the time and expertise available.

What could this mean for your service?

The most interesting part of our CGPN session wasn't the finished prototype. It was the questions it prompted.

What would happen if your team could test several approaches to a problem in the time it previously took to explore one? What could you learn earlier? And where could that free up time for the things that really need human judgement?

Those are the conversations I'd love to continue.

If you're exploring where AI-assisted development, leaner delivery approaches or faster experimentation could make a meaningful difference to your services, we'd be interested to hear what you're working towards and exchange ideas about what's now possible.