Counter-arguments

The suppliers, products and customers discussed in the survey are in the landscape database, with known spend and sources. The graph shows how they connect.

The CIC’s digital-sovereignty thesis does not apply everywhere. This page sets out the cases where it does not, the record of past UK public-sector digital programmes, and the risks the CIC has to address.

Where commercial procurement is the better option

Several conditions favour buying a commercial product over building or adopting an open one:

• Mature product, competitive market, modest lock-in. Where suppliers compete on price and features and switching is feasible, procurement works as intended. Some council products do compete this way; some HE products do.
• Highly specialised domain knowledge built over decades. A small number of clinical, engineering, and scientific products carry deep domain expertise that is uneconomic to replicate for the size of the buying market. Some genomics tooling, some specialist clinical decision-support systems, some medical-device-adjacent products fall here.
• Vendor commitment to interoperability. A few suppliers have invested significantly in open APIs and data portability. Where they have, some of the CIC’s objections no longer apply.
• Regulated markets where certification cost is the dominant economic feature. Where certification cost is much larger than other costs, a single well-resourced vendor spreading that cost across many buyers may produce better outcomes than a federated open effort.

The CIC’s thesis is limited to this: where current procurement serves the public sector badly, there should be a credible alternative. It does not claim that every commercial product should be replaced, and where procurement works well the survey says so.

The historical track record of UK public-sector digital programmes

Any proposal for new public-sector digital work has to account for what has gone wrong before. The main cases are set out below.

National Programme for IT (NPfIT, 2002–2011)

The largest public-sector IT programme ever attempted in Europe. Estimated cost £9.8bn at the time the programme was effectively dismantled, against an original budget of £6.4bn High. The intended national EPR was never delivered. Many of the dependencies (Spine, e-Referral, electronic prescribing) survived as separate national services.

What it tells us. A single centrally imposed system did not serve local users whose operations varied widely. The parts that survived (the infrastructure layer) were narrow, reusable, and did not dictate workflow.

Universal Credit (2010–present)

Originally architected by major SIs in the early 2010s. The 2013–2015 reset brought delivery substantially in-house at DWP. Cost ran significantly above original estimates, but after the move in-house DWP produced a system that works at national scale.

What it tells us. A programme that was failing recovered after it was reset around in-house engineering. This is the strongest central-government precedent for the CIC’s engineering-led model.

HMCTS Common Platform

A long-running criminal-case-management programme, with significant delivery problems, repeated reset reviews, public criticism from court staff and the judiciary, and industrial action.

What it tells us. Even publicly-owned, in-house-led programmes can struggle when scope is too broad, governance is unclear, and the engineering quality of the delivery is not consistently high.

Verify (2013–2022)

The original GOV.UK identity programme. Designed for federated, privacy-preserving identity but never reached adoption beyond a small number of services. Phased out in favour of One Login.

What it tells us. A well-designed architecture did not on its own lead to adoption. The departments needed something simpler than Verify. One Login is less federated but easier for departments to integrate, and has been more widely adopted.

The post-pandemic procurement wave

The acceleration of cloud and SaaS adoption during 2020–2022, often via emergency procurement routes, locked many parts of the public sector into Microsoft, AWS, and Google ecosystems with limited exit terms. The sovereignty cost of those decisions will become clear over the next decade.

Risks the CIC has to address to be credible

Governance of public codebases

The largest risk to a publicly owned codebase is that, five years later, nobody is responsible for it. The CIC supports every system it builds for as long as the client needs it. That commitment depends on the CIC continuing to exist, so each engagement also needs a plan for who maintains the system in 2035: documented governance, more than one maintainer, an institutional steward where one exists, and trained staff on the client’s side who take on more of the day-to-day support over time.

The bus factor

Small teams, including the CIC, are vulnerable to individual departures. A two-person engagement that loses its lead engineer mid-project is in serious difficulty. Public-sector open source has many abandoned projects that depended on one individual. Mitigations: at least two engineers on each substantive engagement, more documentation than would normally be written, and planned knowledge transfer.

The maintenance burden

Most of the long-term effort is in keeping software secure, up to date, integrated with changing dependencies, and compliant with changing statutory obligations. The initial build is the smaller part. The CIC’s reserve fund helps pay for its support commitments, but it cannot cover maintenance across many engagements at once, so the number of active engagements per CIC engineer has to be limited.

Sustainability of public codebases beyond the CIC

The CIC may not exist indefinitely, and even while it does it cannot be the only maintainer of every codebase it produces. It therefore documents each system and trains the client’s staff throughout the engagement, so that the client can handle more of the day-to-day support over time; the client decides the pace. Handover is the point at which a named person on the client’s side can run the system day to day, and the CIC continues to support the system after that. If only the CIC could maintain a client’s code, the client would depend on the CIC in the same way it currently depends on a vendor.

Replacing one monoculture with another

Replacing one vendor monoculture with one CIC monoculture would be worse than the current position. The CIC’s engagements should produce code that any competent team could fork, maintain and extend. Open licensing, public repositories and portable architectures are the means of ensuring this.

Political volatility

Public-sector buyers are subject to political change. A change of government, a change of accountable minister, or a high-profile incident can derail a programme regardless of its merits. Engagements need to be structured so that intermediate deliverables are useful even if the final goal is not reached.

Limits of the CIC’s model

The CIC’s working assumption is that small experienced teams using agentic development tools can deliver projects of a suitable size more efficiently than large SI programmes. This does not hold for larger work. Some problems require hundreds of engineers, integration work over several years, and governance structures that the CIC will not have. The CIC has to identify correctly which problems fit its size.

In summary: the CIC aims to deliver small and medium-sized public-sector engagements at lower cost than the usual alternatives. It can contribute components to long-term work (shared platforms, sovereignty infrastructure) that no small team can deliver alone. It will not replace HMRC’s tax estate or build a federated data platform on its own.