172 digital services. More than 60 departments, agencies and local authorities. 3,200 applications. Deployments more than 122 times a day. 99.95% uptime.
That is GOV.UK PaaS in July 2022, on the day the Government Digital Service announced it was shutting it down.
By every operational measure in the platform engineering canon, it worked. It was decommissioned anyway, and the reasons GDS gave are the most useful thing published on this subject.
Here is the line the rest of this hangs on: a platform is not an asset you build, it is a bet that a particular gap is worth closing, and the gap closes without telling you.
A word on where this comes from, because it should change how you read it. I run workplace technology for 25,000 people, which is enterprise IT rather than product engineering. I have never stood up a Backstage instance. What follows is not a war story. It is what the published evidence says when you go and read it, and the evidence turns out to be stranger than the advice built on top of it.
What actually closed GOV.UK PaaS
GDS gave three reasons. Growth had stalled. The large cloud providers had, in their words, "upped their game and reduced the barriers to entry". And departments had built their own cloud engineering capability and were clustering around a Kubernetes based architecture on their own.
The tempting move is to pick whichever of those supports the argument you already hold. Read the first on its own and this is a straightforward adoption failure. Read the second and third on their own and it is pure market movement, nobody's fault.
They are the same event seen from two ends.
Growth stalls because the gap is closing. A team that can now stand up its own thing in an afternoon does not join your platform, and the number that surfaces on your dashboard is flat adoption. So adoption is the symptom you can see, and scarcity is the disease underneath it. That distinction is not academic, because it changes what you monitor. Adoption tells you how you did last quarter. Scarcity tells you how long you have got.
Every internal platform is an arbitrage on the difference between what your organisation can do on its own and what the market makes easy. That difference is the whole value of the thing. It narrows every year, and nobody sends you a note when it does.
One detail worth sitting with. The UK government's roadmap for modern digital government commits to a fresh generation of shared platforms, including a new one called internal.gov.uk "for people who work in the public sector to connect via instant messaging functionality, forums and a secure code repository", due June 2026. It makes no reference to GOV.UK PaaS, and gives no account of why the last one was retired.
The organisation that wrote the best post-mortem in this field did not cite it in its own next plan.
The literature was not written for you
If you run an enterprise IT estate rather than a product engineering organisation, this is the part that matters.
Look at who the examples are. Team Topologies publishes thirteen platform team industry examples. Exactly one is public sector. The rest are Docker, Flo Health, Trade Me, Improbable, PureGym, Footasylum, Uswitch and similar. Every prescription in the field, golden paths, thinnest viable platform, stream-aligned teams, cognitive load, assumes a population of product engineers shipping services they own.
That is not most enterprise IT. If your estate is Microsoft 365, a service management tool, a fleet of endpoints, a dozen line-of-business applications and a handful of integrations, your users are not stream-aligned product teams. Your cognitive load problem is not deployment pipelines. And your adoption problem is not that developers prefer their own tooling, it is that a department will buy a SaaS product on a corporate card rather than wait for you.
The strange part is that the canonical definition already covers you. CNCF's platforms white paper says platform users "include but aren't limited to app developers and operators, data scientists, COTS software operators, and information workers". Information workers are in the founding definition. Almost nothing built on top of that definition acknowledges they exist.
The one author writing directly for this audience is Gregor Hohpe, whose 2024 book Platform Strategy has a substantial in-house IT section, including one titled "IT Platform and IT Services Are Antonyms". His failure mode for enterprise platforms will be familiar: outdated by the time they launch, restricting rather than enabling, and mandated in a last-ditch attempt to make the economics work. His evidence base is a decade of practitioner experience rather than measurement, and he names no organisations.
And the evidence under the advice is thin
Worth knowing before you cite any of it at your own leadership.
Start with the number everyone repeats, some version of "70% of platform initiatives fail". The New Stack repeats it and, to its credit, links its sources, which is how you can check them. Follow the first link and the "up to 70%" traces to a webinar registration page titled "Platform leadership 101: Why 67% of platform initiatives are failing", whose entire stated methodology is a single sentence: "Both our community surveys and broader market studies reveal that 67% of platform leaders are missing the mark on building successful, scalable Internal Developer Platforms." Follow the second, for the claim that half of platform teams are disbanded within eighteen months, and you reach a Gartner topic page that does not contain that claim at all. Its only statistic is a forecast that 80% of large software engineering organisations will have platform teams by 2026.
So the citation is not thin. It is broken.
The academic position is documented, and it is worse. A multivocal literature review published in Frontiers in Computer Science in May 2026 searched five databases and found "fewer than a dozen peer-reviewed papers from reputable venues that address platform engineering directly". No tier-A source proposes or validates a maturity model, so every maturity model in circulation comes from grey literature. And on scorecards, the main governance mechanism inside most developer portals, it found "no peer-reviewed empirical evidence of effectiveness exists despite widespread commercial adoption".
Be fair to the method here: a multivocal review deliberately includes grey literature, so a low proportion of academic sources is partly the point of the technique. The absolute count is the number that bites. Fewer than a dozen papers, for a discipline with a conference circuit and a tooling market.
The canonical artefacts have not aged well either. The CNCF Platform Engineering Maturity Model was released in November 2023 and is still v1.0. The working group that owned it no longer exists: when CNCF restructured its technical groups in May 2025, the assessment work was recorded in CNCF's own tracker as "having paused in recent months due to recent TOC changes", with the authors asking that the TOC "provide guidance as to the correct place within the community to conduct this ongoing work". A pilot assessment tool has since appeared outside the CNCF repositories, still asking for feedback.
None of that means platform engineering is wrong. It means the confident numbers in your inbox are not measurements, and you should discount accordingly, including the ones in this piece.
What is actually measured, including the uncomfortable part
DORA's 2024 report, nearly 3,000 respondents, is the strongest measured evidence in the field. Internal developer platform users showed 8% higher individual productivity and 10% higher team performance.
Throughput also decreased by 8%, and change stability decreased by 14%.
That is the field's flagship research reporting that platforms made delivery slower and less stable. DORA's own hypotheses are that a platform can add handoffs between systems and teams, or that it lets teams ship faster and therefore break more, or that instability signals teams were never properly onboarded. The report links that instability to increased developer burnout, and cautions against deploying platform engineering as a burnout remedy.
DORA's 2025 report, nearly 5,000 technology professionals, adds the finding that matters most right now: when platform quality is high, the effect of AI adoption on organisational performance is "strong and positive", and when platform quality is low that effect is "negligible". If you are being asked to demonstrate returns on AI, the platform is not a competing priority. It is the precondition. That is the strongest argument for doing this work I have found anywhere, and note that it is conditional on quality rather than on existence.
One discrepancy worth carrying. DORA 2025 reports 90% of organisations have adopted at least one platform and 76% have dedicated platform teams. A CNCF and SlashData survey of more than 400 developers in March 2026 found only 28% have a dedicated platform engineering team. Those two are not describing the same thing. When someone quotes an adoption figure at you, ask what they counted.
Nobody uses these things
Spotify, the company that created Backstage, has publicly estimated the average Backstage adoption rate at 10% inside the organisations that install it. Nine in ten of the people it was built for carry on as before.
The vendor surveys agree, which is notable given who pays for them. State of Platform Engineering Volume 4, published by Weave Intelligence with 518 respondents, found that "nearly 30 percent of platform teams still report that they do not measure success at all", and that adoption "is still frequently driven by extrinsic push or mandate (36.6%) rather than the intrinsic value necessary for true user pull (28.2%)".
Which returns you to where the idea started. When Evan Bottcher defined the digital platform in 2018, one word was doing real work: "a foundation of self-service APIs, tools, services, knowledge and support which are arranged as a compelling internal product". Compelling, not mandated. A platform that needs a mandate has already failed its own definition. Even Microsoft's guidance, which has every commercial reason to encourage you, says it plainly: "Customers should want to use your platform, but not be mandated to use it."
That advice is correct, and in a regulated enterprise it is unusable as written. Which brings me to the part the literature does not cover.
Three things I would do differently
Mandate the control, never the path. In a bank, an insurer, a hospital or a government department, "don't mandate it" is not available to you, because an unpaved road is an audit finding. So mandate the outcome instead: encryption, identity, logging, network placement, data residency. Leave the route optional. This costs you nothing you actually needed, and it buys you the only honest adoption metric there is, because now the percentage of compliant workloads that came through your paved road tells you how many teams chose you when a legal alternative existed. Compare that with measuring how many workloads are compliant, which measures your auditors rather than your platform.
Your service catalogue is the portal you already have. Microsoft's own advice is that a developer portal is "a destination rather than a starting point", and that you should extend the surfaces people already use before you build a new one. In enterprise IT that surface is the service management tool, because it is where people already go when they want something. Self-service in this world usually means a request with an approval attached, not a git push, and there is no shame in that. Building a second front door and then asking the organisation to learn it is how you arrive at 10%.
Put the expiry review in the diary, and decide now who raises it. Every six months, write down what your platform makes easy, then price what it would cost a team to do that today without you, using whatever the hyperscalers shipped last quarter. If the answer is "about the same", you are running GOV.UK PaaS in 2022. The second half of that sentence is the hard one. Nobody retires a platform without embarrassment, because the person best placed to notice the gap has closed is the person whose job closes with it. GDS could do it because GDS had plenty of other work. A platform team inside a bank has no such luxury, and that, rather than sunk cost, is the real reason platforms outlive their scarcity. Name the person who is expected to raise it while naming them is still cheap.
Underneath all three sits the question nobody writes about: who funds this. In a product organisation the platform team is paid for out of engineering and nobody asks again. In enterprise IT it is funded by whoever will sign for it, and an unmandated central platform re-justifies its budget every year against projects with a named business sponsor, and loses. The person who signs is also the person who will be asked at the next audit why the controls are not uniform. Which is the first recommendation again, arriving from the other direction.
The two things that are both true
The discipline's own flagship research says platforms reduced throughput and stability. Its most-quoted failure statistic traces to a webinar title and a Gartner page that does not contain it. The company that built the most popular portal puts adoption at one in ten.
And the platform is still the thing that determines whether your AI spending returns anything at all.
You hold those together by changing what a platform is for. Not an asset you build and then defend, but a bet on a gap, priced at the start, repriced on a schedule, and closed without embarrassment when the market closes it for you. GOV.UK PaaS was not a failure. It was a correct decision at the beginning and a correct decision at the end, and the only mistake available was keeping it because shutting it down would have looked like one.
Start by writing down which gap you are betting on. If you cannot name it in a sentence, you do not have a platform, you have a project.
If you are building on Azure, two of the services most commonly recommended as the foundation went into maintenance mode this year. That is a separate post: Azure Deployment Environments and Dev Box are in maintenance mode.