The constant gardener: nurturing public sector digital services

Too often, digital transformation is treated like a one-off initiative: scope it, ship it, forget it. 

But in the public sector, where lives and livelihoods are impacted, going live is just the beginning. The real value and risk, starts when people begin using the service. For government digital teams, success isn’t measured by a launch date - it’s measured in continuity, trust and services that quietly work when people need them. 

Like a well-kept garden, the best services need: Care + Attention + Time. Otherwise, trust fades, costs rise and users quietly find other ways to get what they need or, they complain and negatively impact the business in a different way.

This isn’t a call to romanticise maintenance - it’s about facing the reality that services live and breathe. And if we want them to thrive and flourish, we need to look after them. 

Caring for digital services 

A healthy service doesn’t just do the job; it improves somebody’s life in some way. It adapts. It responds to the changing world around it and the changing users who use it. That means having the basics in place: observability, monitoring and alerting. But it also means routines and mechanisms that allow teams to spot and solve problems before they impact businesses. 
 
Regular refinement matters. It removes unused features, improves accessibility and the user experience and keeps code clean and easy to develop, expand or fix. Automation supports the day-to-day to avoid regressions, but it’s the people who’ve built and cared for the service who carry the real value. 
 
One company I worked with did the opposite. They handed off the development of their APIs to a third party, with no long-term plan to maintain them after development was “completed.” There was no maintenance, no documentation and no continuity. Over time, performance dropped, data bugs became more prevalent and upgrades became impossible. Eventually, the whole system had to be rebuilt from scratch with no documentation or specs, at a significant cost and under immense pressure due to the number of live users. 

Contrast that with another organisation that took a long-term view. They agreed to embed quality from the start (and even implemented a company-wide behaviour around doing things with quality in mind).  They tracked meaningful industry-recognised metrics and refined the service continually for end users, as well as the engineering teams working on the services. Years later, their systems are still fast, accessible and resilient – so much so, that new joiners into the Engineering team can safely deploy to production on day one. 

When you plant something, you look after it, monitor it, care for it, check for signs of stress or disease. You water it and feed it and you hope all that effort and care results in a happy, healthy plant that you and others can enjoy for a long time to come. The same applies to digital services. QA shouldn’t stop at launch; it needs to evolve with the service. That means monitoring, checking for regressions, testing in production-like environments and exploring what happens when real users interact with live systems in expected (and unexpected!) ways. 
 
Testing in live services becomes less about pass/fail and more about confidence, risk and outcomes. It's how you avoid "avoidable contact", monitor user pain points and preserve institutional reputation.  
 
However, this only works if teams stay close. Embedded delivery teams with shared context and retained, documented knowledge are best placed to respond quickly and make meaningful improvements. When QA is present, questions get asked: 

Without that presence, those questions being asked and thinking about the things users may or may not do on a behavioural and technical level, services stall. People stop touching code out of fear. Small problems turn into major disasters. And users? They just stop using it or if they have no other choice, they complain until they are heard. 

Measuring your investment 

If all you measure is the point you spotted a seedling, you’ll miss whether it ever turns into a magnificent oak tree. A service may well launch on time and even occasionally on budget, but that doesn’t mean it’s working as intended, nor delivering value to clients. 
 
Good KPIs look beyond go-live. They ask: Are users completing their tasks? Where are they getting stuck or dropping out of the funnel? Is performance holding up? Are we delivering improvements regularly and painlessly and are they based on real feedback, rather than gut feeling? 
 
I’ve seen teams use dashboards that surface user drop-off points in real time. That kind of visibility helps you spot what’s overgrowing, what’s wilting and where new value should be planted next. There is no need for a long review meeting; the problem is right there, visible to many sets of eyes and it can be acted on swiftly. 
 
Pair KPIs with lightweight and fast feedback loops and regular team retrospectives. That’s how you create momentum and consistent, meaningful reflection. 

Your road ahead 

The biggest shift isn’t in tooling or contracts; it’s in mindset. Services aren’t projects. They’re systems. Living, evolving, imperfect systems. 
 
If we treat them that way, everything changes. We stop chasing finish lines. We start thinking about continuity, stewardship, iteration and responsiveness. And ultimately, we think about the people that are being served. 
 

Neglect has a cost – Rebuilding trust, redoing work, repairing reputation and fielding complaints. 
 
Care has a return – Happy users and teams. Stability. Confidence. Growth. 

So here’s the ask: 

Because in the end, people don’t remember how fast you launched. They remember whether it worked when they needed it most. 

At 2i, we’ve helped public sector teams across the UK avoid costly rework, embed resilient QA practices and deliver high-quality services without drama. 

Let’s talk about how we can help you empower your team and protect your users.  

Get in touch