Both sides of the classical debate are answering the wrong question. The real choice is not whether to build or to buy — it is whether to own the configuration or to own the source code. Reframing the question changes every decision that follows.
Every five years, every government rediscovers build-versus-buy. A new minister arrives, a budget is challenged, a procurement scandal breaks, and the question is asked again as though for the first time. By now the literature could fill a wing of the archives. And yet the decisions made on the back of it are no better than they were thirty years ago. There is a reason for that. The question is poorly formed.
The classical build-vs-buy frame assumes two clean alternatives. Build, and you control everything, but you carry every cost and every risk. Buy, and someone else carries the load, but you depend on a vendor whose interests are not yours. The frame produces an unwinnable trade-off. So agencies oscillate. They build, the project overruns, an enquiry concludes that the public sector should not build. They buy, lock-in becomes unbearable, an enquiry concludes that the public sector has lost control. The cycle repeats. Each enquiry is shocked to find the conclusion of the last enquiry vindicated.
The dichotomy fails because it confuses two different questions and pretends they are one. The first question is who writes the source code — an internal team, a contracted developer, a product company. The second question is who owns the running configuration — the schemas, the workflows, the business rules, the user interface arrangement, the integrations. The two questions point at different things and have very different answers.
The ownership of source code matters far less than is supposed. The ownership of configuration matters far more. When agencies talk about "control" what they almost always actually need is configuration ownership. When they talk about "independence" what they almost always need is configuration ownership. Most build projects exist because someone, somewhere, conflated these two things.
Consider a tax authority running an enterprise platform. The platform is two million lines of source code. The configuration — the tax types, the assessment rules, the appeals workflow, the deduction logic, the integration with treasury, the reporting templates, the user roles — is perhaps fifty thousand lines of declarative data. The two million lines change rarely. The fifty thousand lines change every budget cycle, every legislative amendment, every operational review. The fifty thousand lines are the system, as the tax authority experiences it.
Now ask: of those two parts, which one does the agency need to own? The source code can be owned by any of several parties without changing the tax authority's day-to-day. The configuration cannot be owned by anyone but the tax authority and survive contact with reality. When the legislature passes a midnight amendment to the VAT regime, the tax authority needs to be able to make the change. Not requesting a feature. Not raising a ticket. Making the change.
With the right question, the matrix becomes four boxes rather than two. Source code can be in-house or vendor-owned. Configuration ownership can be in-house or vendor-controlled. Each combination has different properties.
Vendor source code, vendor-controlled configuration. The classical "buy" scenario. Implementation partner sets up the configuration. Agency depends on the partner for every change. Vendor lock-in is total. Migration is unthinkable. This is the configuration most procurement scandals are written about.
In-house source code, in-house configuration. The classical "build" scenario. Agency owns everything. Carries every cost. Inherits every risk. Most ambitious projects in this quadrant fail not because the engineering was bad but because government agencies are not optimized to be product companies. Continuity is fragile.
Vendor source code, in-house configuration. The configuration-owned model. Vendor maintains the platform — updates, security, performance, scalability. Agency owns the schemas, workflows, rules, integrations, reports, screens. Most platform changes are configuration changes, made in-house. Source-level changes are rare and deliberate.
In-house source code, vendor-controlled configuration. The accidental hybrid. Agency built the platform but lost institutional knowledge. The vendor brought in to maintain it now controls the configuration in practice. The agency owns code it cannot meaningfully change. Worst of both worlds.
The third quadrant — vendor source, in-house configuration — is where most successful modern public-sector deployments end up. It is also where most failed ones could have ended up had the agency made one architectural decision differently at the start: insisting on a metadata-driven platform.
A metadata-driven platform expresses its business logic as data rather than as code. Schemas, workflows, validation rules, reports, screens, integrations — all live as configuration that can be edited by an analyst rather than a developer. Code is reserved for the platform itself; configuration is reserved for the agency's actual work. When the platform is built this way, the configuration becomes a transferable asset. It can move to a new vendor. It can be audited by the agency's own staff. It can be backed up, versioned, restored. It is the agency's intellectual property in a form the agency can actually carry.
If configuration ownership is the real prize, procurement should be written around it. Three clauses do most of the work.
First, the platform must permit the agency's staff to author and modify configuration without recourse to the vendor. Configuration changes are defined and enumerated in the contract. A change-control SLA for vendor-side changes is set only for source-level work.
Second, the configuration is the agency's property. Not licensed back. Not held in escrow. The agency's property. The vendor receives a perpetual licence to access the configuration for support purposes only; ownership remains with the agency.
Third, the configuration must be expressed in a format that survives the vendor. A documented schema. An export mechanism. Where possible, an open or de facto standard. The test: if the vendor disappeared tomorrow, could a successor read the configuration and continue running it? If not, ownership is fictitious.
Almost every downstream decision shifts. The team you hire is no longer a development team but a configuration team — analysts who understand the regulatory or operational domain, who can model it, who can manage the change pipeline. The training programme shifts from coding skills to platform-specific certification, of the kind we publish through the Emeron Academy. The audit posture shifts from code review to configuration review — an entirely different discipline. The succession plan shifts from preserving developer capacity to preserving configuration documentation.
Above all, the procurement debate stops being about ideology. There is no longer a build camp and a buy camp shouting past each other. There is a configuration-ownership test. Either the proposed arrangement passes it or it does not. The procurement officer can adjudicate the question with evidence rather than slogan.
There are cases — rare, but real — where the agency genuinely needs to own the source code as well. Classified workloads where no vendor relationship is acceptable. Strategic platforms that the state regards as critical infrastructure in the geopolitical sense. Greenfield innovation where no product exists and the agency is creating a new category. In those cases the build quadrant is correct. The point of the reframing is not to disqualify it — it is to make sure agencies choose it deliberately, with eyes open, rather than by default.
For the eighty percent of public-sector software work that does not fall in those categories, the configuration-owned model is the answer that has been hiding behind the question all along.
This essay is the public summary of Whitepaper WP-01 (62 pages, reviewed). The whitepaper includes the full decision matrix, three case studies, and a sample procurement clause set.
Practical screening questions that surface vendor lock-in before it is signed into a multi-decade dependency.
Read essay →What sovereignty actually requires at the infrastructure layer, and why it is not solved by the cloud provider's marketing.
Read essay →The technical companion to this essay. How metadata-first platforms work, and what it takes to bring the model to government.
View whitepaper →Senior teams in central agencies, audit committees, and supervisory boards have asked us to deliver this material as a private briefing. We do so without charge for organisations exploring a platform decision in the next twelve months.