Topic 5.3 — Public Sector Software Engineering and Platforms

Why this matters in public value

Nearly every public service a citizen touches today — registering a birth, claiming a benefit, paying a tax bill, booking a court date — runs on software somewhere behind the counter or the screen. That software is rarely a one-off purchase; it becomes part of the state's permanent infrastructure, often outliving the administration that commissioned it, the supplier that built it, and the programming language its engineers were trained in. A public body does not experience software the way it experiences a building or a road, where the asset's condition is visible; software degrades invisibly, and the bill for that decay arrives years later as an emergency.

The tension driving this topic is structural. Software is inherently iterative — requirements become clearer as users interact with a working system, and the best engineering practice is to build something small, learn, and adapt. Public procurement and accountability cycles (see Topic 3.7 — Public Procurement and Commissioning), by contrast, were built for capital works and defense contracts: a fixed specification, a single large award, milestone payments, and a business case signed off years before delivery begins. When a legislature or an auditor expects a fixed-price, fixed-scope contract and an engineering team needs to change course after the first release, the mismatch shows up as scope creep, budget overrun, or a system specified correctly in 2019 and obsolete by the time it ships.

The platforms this topic's engineering practice exists to build — shared identity systems, payment rails, case-management tools reused across departments — are the subject of Topic 5.1 (see Topic 5.1 — Digital Government and Digital Transformation); this topic is about the discipline of building and buying the software that makes any such platform, or any single service, reliable, replaceable, and owned by the public body that depends on it rather than by whichever supplier happened to write it first.

Core concepts

The build-versus-buy decision is the choice between commissioning bespoke software written for one organization's need and adopting configurable commodity software already built for a market of similar buyers. Buying is usually cheaper and lower-risk for a need that is not genuinely distinctive — payroll, email, standard case management — while building is justified only where the requirement is different enough that no configurable product fits, or where the capability is itself a strategic asset the organization needs to own and evolve.

Technical debt is a metaphor, coined by the software engineer Ward Cunningham in 1992, for the accumulated cost of choosing an expedient way to ship software now over a more thorough way that would have taken longer. Technical debt, like financial debt, is not inherently wrong to take on — Cunningham's own point was that shipping working code quickly and refactoring afterwards can be the right call — but debt that is never repaid accrues interest as slower delivery, more defects, and rising risk, and a public body that cannot see its debt cannot decide whether to service it or let it compound.

A legacy system is an old technology, application, or platform that remains in active use despite being outdated, often because replacing it is expensive or because nobody left in the organization fully understands what it does. Legacy systems are especially persistent in government: core tax, benefits, and social-insurance systems written decades ago in languages such as COBOL — the Common Business-Oriented Language, designed in 1960 for administrative computing — still process transactions for millions of citizens, because the systems work and the institutional knowledge needed to safely retire them has often retired itself first.

Software modernization is the general term for converting, rewriting, or migrating a legacy system to a current architecture, language, or platform. Software modernization spans a spectrum from a full rewrite to more conservative options such as re-hosting the same code on modern infrastructure, and the choice between them is as much a risk-management decision as a technical one.

The strangler fig pattern is an incremental modernization approach, named after a vine that grows around a host tree and gradually replaces it, in which new functionality is built alongside a legacy system and traffic is redirected to it piece by piece, rather than replacing the whole system in one cutover. The strangler fig pattern matters because it lets each increment be tested, rolled back, or paused without taking the whole service down — the opposite of a big-bang replacement, where the old system is switched off and the new one switched on in a single moment with no way back if something is wrong.

Vendor lock-in occurs when a customer becomes so dependent on one supplier's proprietary technology, data formats, or contractual terms that switching to another supplier carries prohibitive cost or risk. Vendor lock-in is a particular danger in public-sector software because the buyer is a repeat customer with limited practical ability to walk away from a system running a critical service, which weakens its negotiating position on every subsequent renewal.

Free and open-source software is software distributed under a license that grants users the freedom to use, study, modify, and redistribute the source code. Free and open-source software underpins an open-source-by-default policy, under which a public body defaults to publishing the source code it commissions unless a specific reason — security sensitivity, third-party rights — justifies withholding it; the rationale is usually summarized as "public money, public code": software paid for once with public funds should not need to be paid for again, in a different jurisdiction, by a different public body solving the same problem.

A digital public good is open software, data, or content, released under an open license, designed to help meet a public development or governance objective rather than generate a commercial return. Digital public goods reframe one government's open-source release as part of a wider, shared infrastructure other governments and civil-society organizations can draw on directly, not only an internal transparency gesture.

Agile software development is an umbrella term for iterative approaches to building software that favor working software, frequent delivery, and responding to change over following a fixed plan agreed in advance. Agile software development stands in contrast to the waterfall model, a sequential approach in which requirements, design, build, and testing each complete fully before the next begins; waterfall's appeal to public bodies has always been that its milestones map neatly onto a fixed-price contract and an annual budget cycle, which is why so much procurement law still assumes it, even where delivery is genuinely agile.

A minimum viable product is the smallest version of a service that can be released to real users to test whether it works and learn what to build next. The minimum viable product concept, adapted into public-sector digital-service playbooks, gives an iterative team a defensible way to show a funder or an auditor something real and working long before full scope is complete — provided the accountability process accepts a genuinely minimal release rather than treating it as the finished product under a different name.

Best practices

Default to buying for undifferentiated needs, and reserve building for what is genuinely distinctive. Payroll, email, and general case-management needs are rarely different enough from any other organization's to justify bespoke software; build only where the requirement, scale, or the need to own and evolve the capability over decades is genuinely different from what the market offers.
Make technical debt visible before deciding how much of it to carry. Maintain a register of known shortcuts, deferred fixes, and unsupported dependencies for every system in service, reviewed on a fixed cycle, so carrying debt for another year is a deliberate trade-off rather than nobody looking.
Never plan a single, irreversible cutover as the only route off a critical legacy system. Prefer incremental approaches such as the strangler fig pattern that let each piece be tested, reversed, and rolled out gradually; a big-bang replacement of a system millions depend on concentrates years of risk into a single weekend with no way back if something fails.
Treat the source code your organization pays to have written as an asset it owns, not a service it rents. Negotiate source-code escrow or outright ownership at the point of contracting, not after a dispute has started, since a supplier holding the only copy of your critical service's code is vendor lock-in by design.
Publish source code as open by default, and require a specific justification to withhold it. An open-source-by-default policy, applied consistently, turns every department's custom-built software into a shared cross-government asset rather than a one-off cost, and lets outside experts find security flaws an internal team alone would miss.
Write software contracts that make iterative delivery legal, not just technically possible. A contract that pays only against a fixed specification agreed at signature forces a team to choose between honest agile practice and contractual compliance; use staged funding gates tied to demonstrated working software instead of one milestone at the end.
Fund modernization as an ongoing program, not a one-off capital project. A legacy system modernized once and then left for another twenty years accumulates the same risk it started with; budget for continuous, incremental renewal the way a road authority budgets for resurfacing, not a grand replacement once a generation.
Choose open standards and portable data formats even when buying commercial software. Requiring a supplier's system to store and export data in open, documented formats keeps switching costs low even where the software itself is proprietary, and is often a more achievable near-term safeguard against lock-in than insisting every system be open source.
Build a minimum viable product and show it to real users before committing to full scope. Releasing a genuinely minimal version, then iterating on what is learned, catches wrong assumptions while they are still cheap to fix, rather than after a full-scale system has been built against them.
Keep in-house engineering capability sufficient to be an intelligent buyer, even where delivery is contracted out. A public body that has hollowed out its technical expertise cannot assess a supplier's proposal, spot early warning signs of a troubled project, or negotiate its way out of lock-in, whatever its procurement rules say on paper.
Retire a legacy system's risk profile before its user interface. Prioritize replacing unsupported languages, unpatched infrastructure, and undocumented integrations — the failures that cause outages and breaches — ahead of visual modernization that carries far less operational risk.
Measure delivery health with engineering indicators, not only budget and schedule variance. Deployment frequency, defect rates, and the age of the oldest unaddressed technical-debt item tell a governance board more about whether a program will succeed than whether it is currently on budget, often the last indicator to move.

Questions to discuss with your team

Do we actually know how much technical debt we are carrying, system by system? Most public bodies can state their capital budget for the year but cannot state, with any confidence, how much of their software estate runs on unsupported components, undocumented logic, or code nobody remaining on staff fully understands. Use this question to ask each system owner in the room to estimate, honestly, how confident they are that their team could safely change their most critical system without breaking something nobody anticipated. Discuss what it would take to turn those estimates into an actual register, reviewed on a fixed cycle, rather than tribal knowledge that leaves when a key engineer does. Consider, too, who currently decides how much debt is acceptable to carry, and whether that decision is deliberate or by default.

If our most critical legacy system needed to be replaced starting today, would we be planning a big-bang cutover or an incremental migration — and why? The instinct to replace an old system all at once is often driven by budget cycles and program-management convenience rather than technical necessity, and it concentrates enormous risk into a single moment. Use this question to walk through, concretely, what a strangler-fig-style incremental migration of your most critical legacy system would actually look like, piece by piece. Discuss what is stopping you from choosing that route today — funding structured around a single go-live date, a governance process that wants one clean milestone, or a genuine technical constraint that makes incremental migration impossible for this system.

Who actually owns the source code for the software our organization has paid to have built, and could we prove it? Many public bodies discover, only when a relationship with a supplier turns sour, that the contract never secured clear ownership or escrow of the code their critical services depend on. Use this question to pull the contracts for your three most important bespoke systems and check, specifically, what each says about code ownership, escrow, and the right to take the code to another supplier. Discuss what would happen tomorrow if your primary supplier for any of those three systems went out of business or refused to continue the relationship.

Where are we defaulting to closed, proprietary software out of habit, when an open-source-by-default approach would serve us as well or better? Open-source-by-default policies exist precisely because most public bodies solve overlapping problems independently, each paying the full cost of software another public body has already built and could have shared. Use this question to identify one system currently being built or specified and ask whether an equivalent already exists as open-source software elsewhere in government, or whether the one you are building could usefully be released for others to reuse. Discuss what specific barrier — security concern, procurement habit, lack of a clear policy — is actually stopping that reuse, rather than assuming it is not relevant here.

Does our procurement and accountability process actually allow honest agile delivery, or does it just relabel waterfall milestones as sprints? It is common for a team to run notionally agile ceremonies while still being funded, governed, and reported against a fixed specification agreed at contract signature, which recreates every waterfall failure mode under an agile label. Use this question to trace one live digital program from its business case through its current governance reporting and ask whether the funding structure would tolerate the program changing direction based on what a genuine early release taught it. Discuss what would need to change in how the program is funded and reported for iterative delivery to be real rather than cosmetic (see Topic 3.7 — Public Procurement and Commissioning).

Do we have enough in-house engineering capability to be an intelligent buyer of the systems we depend on most? An organization that has contracted out all of its technical judgment, not only its delivery capacity, cannot tell whether a supplier's proposal is sound, whether a project is quietly heading for trouble, or what a fair price for the work actually is. Use this question to ask how many people in your organization could credibly review a technical architecture proposal for your most important system, and how that number has changed over the last five years. Discuss what it would take to rebuild that capability where it has eroded, and what your organization loses, in negotiating position as much as in delivery risk, for every year it goes without.

In practice: a public value example

A fictional regional government — illustrative only, not a description of any real jurisdiction — ran its unemployment-benefit claims through a system first written more than thirty years earlier, maintained by a shrinking number of engineers who understood its original programming language. Claims volume had grown well beyond what the system's designers had anticipated, nightly processing runs increasingly failed to complete before the morning's transactions began, and the agency's technology leadership warned that an unplanned outage affecting benefit payments was now a matter of when, not if.

The agency's first instinct was a conventional response to a problem that felt urgent: commission a single large contract to replace the entire system with a modern platform, specified in full up front, delivered against a fixed two-year timeline with one cutover weekend at the end. A pre-implementation review commissioned by the agency's audit committee raised a hard question before the contract was signed: what would happen to benefit payments for several hundred thousand claimants if the new system had an undiscovered defect in its first week of full-scale, live operation, with the old system already decommissioned and no way back.

The agency changed course. It kept the legacy system running as the system of record and began building new claim-intake and eligibility-assessment functionality alongside it, using a strangler-fig approach: each new module was released to a small percentage of new claims first, verified against the old system's parallel output, and expanded only once its results matched. Within eighteen months, the majority of new claims ran through modern components while the original system handled a shrinking residual caseload, with the ability to route any single case back to the old path if something looked wrong. The agency also required, in every new contract issued for this work, that the source code be owned by the agency and published as open source once security review was complete, so that other regional governments facing the same ageing-mainframe problem could adapt the components rather than repeating the same build from nothing.

The full replacement of the legacy system's last residual functions took nearly four years — longer, on paper, than the original two-year big-bang plan promised. But no claimant ever experienced an unplanned outage during the transition, each increment was small enough to be rolled back within hours when a defect was found, and two neighbouring regional governments began adapting the agency's published eligibility-assessment code for their own systems within the first year of its release.

Four sector lenses

Local government

Local government typically runs a large number of smaller, disconnected systems rather than a handful of national-scale platforms, which means technical debt accumulates across many separately procured, separately maintained applications rather than in one visible flagship system. Local authorities usually have the least in-house engineering capability of any tier of government, making the case for buying configurable commodity software over bespoke builds especially strong, and making shared regional or national platforms — the subject of Topic 5.1 (see Topic 5.1 — Digital Government and Digital Transformation) — a particularly high-value route to avoid each authority separately rebuilding the same capability.

National government

National government is where the oldest and most consequential legacy systems tend to sit — core tax, social-insurance, and benefits administration — because these were often among the first large-scale computerization efforts in government and now carry the highest stakes for any modernization failure. National government typically has the specialist commercial and engineering capability to run a genuinely incremental modernization program and to negotiate real code ownership into its contracts, and it is usually the level of government best placed to set an open-source-by-default policy with enough scale behind it to make cross-government reuse actually happen.

Nonprofits and charities are rarely building large custom platforms themselves, but they are frequently on the receiving end of software commissioned or mandated by a government funder — a reporting portal, a case-management system a grant or contract requires them to use — with little influence over its design, its technical debt, or its vendor. A social-sector organization that depends on a government-mandated system inherits that system's failure modes without inheriting any of the leverage to fix them, which is one more reason outcomes-based funding relationships need to account for the operational burden of mandated technology (see Topic 3.7 — Public Procurement and Commissioning), not only the outcome metric itself.

Multilateral and international

Multilateral bodies and development agencies increasingly promote software built for one country's public administration as a reusable digital public good other countries can adapt, rather than each government commissioning an equivalent system from a private supplier at full cost. The distinctive risk here is that a digital public good built to one country's legal and administrative context can be adopted elsewhere with too little adaptation, importing assumptions — about identity, eligibility, or process — that do not actually transfer; the promise of shared, open infrastructure is real, but only where genuine local adaptation capacity accompanies the code.

Common failure modes

The big-bang cutover that fails on go-live. A critical legacy system is replaced in a single, irreversible cutover after years of development with no live production exposure, and a defect that only appears at real scale or in an edge case nobody tested surfaces on the first day of full operation, with no way to revert to the old system because it has already been decommissioned. The cost is measured in missed payments, denied services, or outages affecting exactly the citizens the system exists to serve, at the worst possible moment — the moment everyone was relying on the replacement working.

Silent technical-debt accumulation. Deadline pressure repeatedly wins the argument against the time needed to fix known shortcuts, and each deferral is individually defensible, until the accumulated debt makes even a small change disproportionately expensive and risky. The cost surfaces years later as a system nobody can safely modify, a workforce that has quietly stopped attempting anything but the most urgent patches, and an eventual modernization program far larger and more expensive than continuous, smaller renewal would have been.

Vendor lock-in mistaken for stability. A public body renews the same supplier's contract repeatedly because switching looks too disruptive to attempt, without ever testing what genuine switching costs would be or negotiating for the code ownership and open data formats that would keep those costs manageable. The cost is a permanently weakened negotiating position on price and terms, discovered only when the supplier's service quality declines or its pricing rises and the public body finds it has no credible alternative.

Cosmetic agile. A delivery team adopts agile ceremonies — stand-ups, sprints, a backlog — while the underlying contract, funding, and governance structure still assume a fixed specification and a single go/no-go milestone, so the team reports sprint velocity while actually delivering against a waterfall plan underneath. The cost is that none of agile's genuine benefits — early user feedback changing direction, risk surfaced early — materialize, while the appearance of modern practice makes the underlying rigidity harder for oversight bodies to see and challenge.

Open-source policy without a sustainment plan. A public body publishes source code to satisfy an open-source-by-default policy but treats the release as a one-off compliance step, with no resourcing for reviewing external contributions, patching vulnerabilities, or maintaining documentation. The cost is a published repository that looks open but functions as an unmaintained dead end, which damages trust in the wider open-source-by-default program more than never publishing at all would have.

Maturity model

Sub-dimension	Initiate	Develop	Standardize	Manage	Orchestrate
Technical debt is visible and managed	Debt is undocumented and known only informally by individual engineers	A partial inventory exists for some systems, not reviewed on a fixed cycle	A debt register covers all critical systems and is reviewed on a documented cycle	Debt reduction is funded and tracked against measurable targets	Debt data is shared across the organization's whole estate to prioritize modernization investment
Legacy modernization avoids big-bang risk	Replacement is assumed to mean a single full rewrite and cutover	Incremental approaches are used occasionally, without a consistent method	Strangler-fig-style incremental migration is the documented default for critical systems	Migration progress and rollback readiness are actively measured and reported	Modernization method and tooling are shared and improved across peer public bodies
Build-versus-buy decisions are deliberate	Build or buy is chosen by habit or supplier relationship, not assessed	Some assessment happens, inconsistently, before major software decisions	A documented decision framework is applied to every significant build-or-buy choice	Build-or-buy outcomes are tracked against their original justification over time	Build-or-buy capability and lessons are shared with other public bodies facing the same choice
Source code and data are open by default	Closed, proprietary delivery is the unquestioned default	Open-sourcing happens occasionally, driven by individual teams	An open-source-by-default policy is documented and applied consistently	Published code is actively maintained, with resourcing for external contributions	Published code is reused across government and by other jurisdictions, with reuse tracked as a benefit
Delivery method fits the accountability structure	Contracts and governance assume waterfall regardless of how delivery actually happens	Agile ceremonies are used, but funding and governance still gate on a fixed specification	Contracts and funding gates are structured around demonstrated working software	Delivery health is measured with engineering indicators, not only budget and schedule variance	Procurement and accountability rules are actively adapted, based on evidence, to fit iterative delivery

Checklist

Inventory every critical system's technical debt and review the register on a fixed cycle.
Apply a documented build-versus-buy framework before committing to any significant new software.
For any legacy system replacement, default to an incremental migration method and require an explicit justification for a big-bang cutover.
Confirm source-code ownership or escrow terms in every software contract before signature.
Publish source code under an open-source-by-default policy, with a documented exception process.
Resource ongoing maintenance for every repository published under that policy, not only its initial release.
Require open, documented data formats even where the underlying software is proprietary.
Structure funding gates around demonstrated working software rather than a single fixed-specification milestone.
Build and test a minimum viable product with real users before committing to full scope.
Track deployment frequency, defect rates, and outstanding technical debt as standing governance indicators.
Assess in-house engineering capability against what is needed to be an intelligent buyer, and close identified gaps.
Prioritize unsupported infrastructure and undocumented integrations ahead of cosmetic modernization.

Key sources

GOV.UK Service Standard, Government Digital Service, United Kingdom — a national digital-service standard requiring iterative, user-centered delivery and open standards for public services.
Office of Management and Budget, Federal Source Code Policy (M-16-21), United States — the federal policy requiring agencies to consider reuse and open-source release for custom-developed government software.
Free Software Foundation Europe, Public Money, Public Code campaign — the rationale, developed for a European audience, for releasing publicly funded software source code under free and open-source licenses.
Ward Cunningham, "The WyCash Portfolio Management System" (OOPSLA 1992 experience report) — the original statement of the technical-debt metaphor.
Digital Public Goods Alliance — a multi-stakeholder initiative maintaining standards and a registry for open software, data, and content designed to serve public development objectives.

References

Technical debt — Wikipedia — https://en.wikipedia.org/wiki/Technical_debt
Ward Cunningham — Wikipedia — https://en.wikipedia.org/wiki/Ward_Cunningham
Legacy system — Wikipedia — https://en.wikipedia.org/wiki/Legacy_system
COBOL — Wikipedia — https://en.wikipedia.org/wiki/COBOL
Software modernization — Wikipedia — https://en.wikipedia.org/wiki/Software_modernization
Strangler fig pattern — Wikipedia — https://en.wikipedia.org/wiki/Strangler_fig_pattern
Vendor lock-in — Wikipedia — https://en.wikipedia.org/wiki/Vendor_lock-in
Free and open-source software — Wikipedia — https://en.wikipedia.org/wiki/Free_and_open-source_software
Digital public good — Wikipedia — https://en.wikipedia.org/wiki/Digital_public_good
Agile software development — Wikipedia — https://en.wikipedia.org/wiki/Agile_software_development
Waterfall model — Wikipedia — https://en.wikipedia.org/wiki/Waterfall_model
Minimum viable product — Wikipedia — https://en.wikipedia.org/wiki/Minimum_viable_product
Service Standard — GOV.UK, Government Digital Service — https://www.gov.uk/service-manual/service-standard
Requirements for Achieving Efficiency, Transparency, and Innovation Through Reusable and Open Source Software (M-16-21) — Digital.gov, Office of Management and Budget — https://digital.gov/resources/requirements-for-achieving-efficiency-transparency-and-innovation-through-reusable-and-open-source-software/
Public Money, Public Code — Free Software Foundation Europe — https://publiccode.eu/
"The WyCash Portfolio Management System" (OOPSLA 1992 experience report) — Ward Cunningham — http://c2.com/doc/oopsla92.html
Digital Public Goods Alliance — https://digitalpublicgoods.net/