I've spent over 9 years building digital services for UK local government — across three councils at 3C Shared Services. Here's what I've learned about what actually works in public sector digital transformation, and what the common mistakes are.
Start With the Problem, Not the Technology
The best government digital projects start by understanding what residents and staff actually need, not by choosing a technology platform. I've seen councils spend millions on enterprise platforms that nobody uses because the procurement was technology-led rather than problem-led. The conversation starts with "we need a CRM" or "we need a low-code platform" when it should start with "residents can't easily report a pothole" or "case workers spend 40 percent of their time on data entry."
Talk to your users first. Sit with the staff who use the current system. Watch them work. Ask what's slow, what's confusing, what they've built workarounds for. The insights from two days of user observation are worth more than six months of requirements documents written in a meeting room.
The technology choice should follow from the problem definition, not precede it. Sometimes the right answer is a custom .NET application. Sometimes it's a configured SaaS product. Sometimes it's a spreadsheet with some validation rules. The cheapest and fastest solution that solves the problem is usually the best one — not the most technically impressive.
GDS Standards Matter
The Government Digital Service design principles exist for a reason. "Start with user needs", "do the hard work to make it simple", and "iterate, then iterate again" aren't just slogans — they're the difference between services people use and services people avoid. Apply them even if you're not building a central government service.
The GDS Service Manual is one of the best resources available for building digital services, and it's free. The assessment framework — discovery, alpha, beta, live — provides a structured approach that prevents the most common failure mode: building something nobody wants. Local government isn't required to follow GDS standards, but the principles are universal.
The most valuable GDS practice for local government is the service assessment. Having an independent panel review your approach before you commit significant budget catches problems early. I've seen assessments identify fundamental user needs that the project team had missed entirely, saving months of wasted development time. If your council doesn't run formal assessments, create a lightweight version — even having a colleague from another department challenge your assumptions helps.
Accessibility is another area where GDS standards should be non-negotiable. Government services must be usable by everyone, including people with disabilities. The Web Content Accessibility Guidelines (WCAG 2.1 AA) are the legal minimum under the Public Sector Bodies Accessibility Regulations 2018. Build for accessibility from the start — retrofitting it is expensive and often incomplete.
Legacy Systems Are the Real Challenge
Every council has systems from the early 2000s (or earlier) that are critical to daily operations but painful to maintain. Planning systems, revenues and benefits, housing management, environmental health — these are often the systems most in need of modernisation and the hardest to change. They're typically built on old technology stacks, have no automated tests, and the original developers left years ago.
The answer isn't to replace them overnight. Big-bang replacements of line-of-business systems in local government have a failure rate I'd estimate at over 50 percent based on what I've seen and heard across the sector. Instead, gradually wrap legacy systems in modern APIs and build new interfaces on top. Let the old system continue doing what it does while you incrementally extract functionality into modern services.
This is the strangler fig pattern applied to local government IT. Start by building an API layer that exposes data from the legacy system. Build new citizen-facing interfaces that consume the API. Gradually move business logic from the legacy system to modern services behind the API. Over time, the legacy system shrinks until it can be switched off entirely.
The critical insight is that you don't need to modernise everything at once. Modernise the parts that are causing the most pain, delivering the least value, or creating the biggest security risk. A partial modernisation that improves the daily experience for staff and residents is infinitely better than a complete modernisation that never ships.
Shared Services Work (With the Right Approach)
Sharing development teams across multiple councils makes financial sense. A senior developer costs the same whether they're serving one council or three. Shared platforms reduce duplication — three councils don't need three separate online forms systems. And shared teams maintain knowledge continuity even when staff at individual councils move on.
But shared services only work if you standardise where possible and customise where necessary. Trying to build completely bespoke systems for each council defeats the purpose of sharing. Equally, forcing identical solutions on councils with genuinely different needs creates frustration and workarounds that undermine the system.
The approach that works best in my experience is a shared platform with configurable elements. The core functionality, infrastructure, and deployment pipeline are shared. Council-specific elements — branding, terminology, workflow rules, form fields — are configurable without code changes. This gives each council ownership of their service while keeping the development and maintenance burden centralised.
Governance is the hardest part of shared services. When three councils share a development team, prioritisation becomes politically sensitive. A clear governance framework with transparent prioritisation criteria prevents the loudest council from dominating the roadmap. Regular steering group meetings with representation from all partner councils keep things fair and visible.
Procurement Doesn't Have to Be Painful
Public sector procurement has a reputation for being slow and bureaucratic. It can be, but it doesn't have to be. The G-Cloud framework on the Digital Marketplace allows you to buy cloud services and specialist consultancy without running a full tender process. For services under £20,000, most councils allow direct award without any formal procurement at all.
When procurement is necessary, the key to keeping it manageable is a clear statement of requirements. Vague requirements lead to vague proposals, which lead to lengthy evaluation processes and disappointing outcomes. Be specific about what you need, what success looks like, and what your constraints are. The better your brief, the better the responses you'll receive.
For software development, I recommend against traditional waterfall procurement where you specify every requirement upfront and select a supplier to deliver the whole thing. Instead, procure iteratively — buy a discovery phase first, then use the findings to procure the build phase. This reduces risk because you're making smaller commitments based on better information.
Security and Compliance Aren't Optional
Government systems handle sensitive personal data. GDPR compliance, Cyber Essentials Plus certification, and PSN compliance are baseline requirements, not nice-to-haves. Build security into your development process from the start — security reviews at the design stage, automated dependency scanning in the CI/CD pipeline, penetration testing before go-live, and ongoing vulnerability monitoring in production.
Bolt-on security after the fact is expensive and incomplete. If you've built an application without considering security and then run a penetration test, you're likely to find fundamental issues that require significant rework. It's far cheaper to get security right from the start than to retrofit it later.
Data Protection Impact Assessments (DPIAs) should be standard practice for any system handling personal data. They're legally required for processing that's likely to result in high risk, and they're good practice regardless. A DPIA forces you to think carefully about what data you're collecting, why you need it, how you'll protect it, and how long you'll keep it. This exercise often reveals that you're collecting data you don't need, which simplifies the system and reduces your regulatory burden.
What's Next
Cloud-first policies are driving Azure and AWS adoption across local government. Low-code platforms like Power Platform are handling simpler workflows and forms. AI is starting to appear in customer service through chatbots, automated triage of incoming requests, and document classification. But the fundamentals haven't changed: understand your users, build iteratively, test with real people, and ship working software regularly.
The councils that succeed with digital transformation aren't the ones with the biggest budgets or the newest technology. They're the ones that focus relentlessly on user needs, build small and iterate, and treat technology as a tool for solving problems rather than an end in itself.
How I Can Help
I've spent my career building digital services for UK local government. If your council is planning a digital transformation initiative, modernising legacy systems, or looking for senior .NET and Azure expertise, I'd welcome a conversation. Get in touch for a free 30-minute discovery call where I can share relevant experience and give you an honest assessment of your options. You can also read about my Azure migration and legacy modernisation services for more detail on how I work.