Platform Engineering in 2026: When an Internal Developer Platform Pays and How to Build One

Platform engineering means building an internal product, usually called an internal developer platform, that gives engineering teams self-service paths to build, test, deploy and run software on approved defaults. A developer portal such as Backstage is often its front door, with a catalog of services, owners and documentation. Behind it sit templates, pipelines, infrastructure code and policies. Google's DORA research program, the longest-running study of software delivery, reports that by 2025 "adoption had become nearly universal, with 90% of organizations reporting the use of an internal developer platform and 76% establishing dedicated platform teams."¹ Having a platform is no longer a distinction. What matters in 2026 is whether yours is any good, what it costs and what it controls.

• 90%of organizations report using an internal developer platform, and 76% have dedicated platform teams¹
• 14%drop in change stability among platform users in DORA's 2024 research, alongside an 8% drop in throughput²
• 29.6%of platform teams do not measure success at all, in a 2025 survey of 518 engineers⁹

What the research measured

The most cited evidence is DORA's 2024 report. Platform users had "8% higher levels of individual productivity and 10% higher levels of team performance," and an organization's software delivery and operations performance rose 6% with a platform. The same report found that "throughput and change stability saw decreases of 8% and 14%, respectively, which was a surprising result."² DORA offered two explanations. A platform adds handoffs between systems, and each one adds time. And respondents required to "exclusively use the platform to perform tasks for the entire app lifecycle" saw a 6% fall in throughput, which DORA linked to being forced onto a platform "when it might not be fit for purpose."² Its advice was to be user-centered and to aim for developer independence, the ability to do a task without waiting on an enabling team, which DORA associates with a 5% productivity improvement.¹

DORA's 2025 report, based on nearly 5,000 technology professionals, moved the question from whether to have a platform to how good it is.¹⁰ It found that "when platform quality is high, the effect of AI adoption on organizational performance becomes strong and positive," while with a low-quality platform the effect "is negligible."¹ The platform capability most correlated with a good user experience was "clear feedback on the outcome of my tasks."¹

Beyond DORA, most surveys come from companies that sell platform tools, and they measure pain and adoption more than results. The State of Platform Engineering Vol 4, from 518 engineers, found that 29.6% of platform teams "do not measure success at all," 55.9% of companies run more than one platform and 47.4% of platform initiatives work on an annual budget between $0 and $1 million.⁹ Port, a portal vendor, reports that 78% of engineering teams wait a day or more for SRE or DevOps help.¹¹ Atlassian's 2025 survey of 3,500 developers and managers found 50% lose 10 or more hours a week, "largely due to organizational inefficiencies."¹² Academic work trails all of this. A 2026 literature review in Frontiers in Computer Science found that only 2 of its 88 sources came from top-tier venues with platform engineering as the main topic, and that for scorecards, the main governance tool in portals, "no peer-reviewed empirical evidence of effectiveness exists despite widespread commercial adoption."³

What companies report

Companies publish the scale of their platforms far more often than their payback. The table separates figures a company published itself from those published by a vendor that sold it something.

The pattern is consistent. The strongest numbers come from a company's own telemetry on one narrow job, such as Uber's CI queue. Portal-wide savings figures arrive through vendors. And the figures age: Spotify, which created Backstage, last published an onboarding number in 2021.¹⁵

Where platforms fail

The documented failure is adoption. In 2023 Spotify officials estimated publicly that "the average Backstage adoption rate is 10%" inside the companies that had installed it.²⁰ Backstage now has 3,400 known adopters, by Spotify's count.²¹ Thoughtworks has placed "miscellaneous platform teams" on Hold in its Technology Radar since 2022, describing teams that carry the platform label without "clear outcomes or a well-defined set of customers."²² A portal that nobody opens is a cost with no return, and nearly a third of platform teams would not know, because they do not measure.⁹

The second failure is concentration. A shared platform turns one mistake into everyone's outage. Roblox was down for 73 hours in October 2021, and its postmortem says "a single Consul cluster supporting multiple workloads exacerbated the impact" of two unrelated faults.²³ In January 2023 CircleCI disclosed that an attacker had taken "customer environment variables, tokens, and keys" from its systems, and its customers had to rotate their secrets.²⁴ A platform team has to design for its own failure, with separate control planes for critical services and secrets that expire.

When a platform pays

No research-grade threshold says when to start. The team-size cutoffs in circulation, such as 20 or 50 engineers, come from vendors and marketing sites without a method. The useful guidance is about scope. Team Topologies, the book most platform teams cite, calls for a "thinnest viable platform" and says it "could be just a wiki page" that records which cloud services you use and how.²⁵ For sizing, the best benchmark we found comes from DX, a vendor now owned by Atlassian: across 39 companies, most dedicate 2 to 6% of engineering headcount to central developer productivity, with an average of 4.7%, and the share falls as companies pass 1,000 engineers.²⁶

Four conditions separate platforms that pay from those that drift. There is a named friction with a number on it, such as days to a first deploy or hours waiting for access. Enough teams repeat the same work that a shared default beats each doing it alone. The team stays small and is run as a product: 52% of respondents in Puppet's 2024 survey called a product manager crucial to a platform team's success.²⁷ And the platform is measured from its first week, against the friction it was built to remove and against DORA's delivery measures, so a fall in throughput or stability shows up early.¹

Vendors are retiring platform products

Between 2025 and 2026, AWS, Microsoft and Atlassian each announced the end of a first-party platform or portal product, while open-source foundations strengthened the layer underneath.

The lesson for a build-or-buy decision is to keep the definitions portable. Service catalogs, templates, infrastructure code and policies should live in your Git repositories in open formats, with the portal as a replaceable layer on top. Atlassian's migration guide shows why: Compass scorecards do not carry over to the replacement product and have to be recreated.⁶

What it costs

The largest cost is people. Using DX's average of 4.7% of engineering headcount, a 200-engineer organization would staff about nine people across developer productivity, which covers the platform and the tooling around it.²⁶ Zalando's team of 9 running more than 140 clusters for its engineering teams is the same order of size.¹⁷ A platform that needs far more people than that, relative to the engineers it serves, is usually doing too much.

AI coding agents make the platform the control plane

AI coding agents follow whatever defaults they are given, at volume. That is why DORA calls AI an amplifier and finds it pays off only on a high-quality platform.¹ In the same research, 90% of respondents used AI at work and 30% reported little or no trust in the code it generates.¹⁰ The platform is where an agent's permissions, network access and audit trail are set, so it is where agent risk is managed.

Portals are adding Model Context Protocol (MCP) servers so agents can query the catalog and trigger actions, but maturity varies. Backstage's MCP integration arrived in version 1.40 and is "highly experimental and could be subject to breaking changes."⁴¹ Port launched its MCP server in June 2025 noting that agents using it "cannot yet execute actions."⁴² GitHub's remote MCP server became generally available in September 2025 with OAuth-based authentication.⁴³ The controls need checking too. GitHub's documentation says its Copilot coding agent firewall "only applies to processes started by the agent via its Bash tool" and that "sophisticated attacks may bypass the firewall."⁴⁴ A platform for agents needs scoped, short-lived credentials, an allowlist of MCP servers and network destinations, and logs a security team can read.

Supply-chain attacks run through the pipeline

The strongest case for a platform in 2026 is control of the build-and-publish path, because that is where the major supply-chain attacks of the past three years ran.

Guidance alone does not change these defaults. Datadog's State of DevSecOps 2026 found that only 4% of organizations pin all public GitHub Actions to commit hashes, the median dependency is 278 days out of date and 50% of organizations adopt new library versions within 24 hours of release, the window in which worms spread.⁷ Verizon's 2026 Data Breach Investigations Report found that exploiting software flaws, at 31% of breaches, has passed stolen credentials as the top entry point for the first time, and that third parties are now involved in 48% of breaches.⁴⁹ A template that pins, scans and signs by default changes these numbers for every team at once, and policy as code enforces them at deployment.³²

Rules that ask for evidence from every build

Cost control follows the same route. The State of FinOps 2026, with 1,192 respondents representing more than $83 billion in annual cloud spend, names shift left, giving engineers cost information before they deploy, as a top priority and reports growing partnership with platform engineering teams. It also found 98% of respondents now manage AI spend.⁵⁵ The waste is structural: CAST AI, a vendor, measured average CPU utilization across Kubernetes clusters at just 10% and memory at 23% across more than 2,100 organizations.⁵⁶ Platform defaults address this directly, with resource requests and autoscaling set in templates, required ownership tags, preview environments that expire and policies that reject oversized resources.

How to build a platform that pays

1. 1Measure the friction Record time to first deploy, waiting time for environments and access, change failure rate and the hours teams spend on pipelines and audits.
2. 2Pick one path Choose the most repeated job, usually a new service from repository to production, and make it self-service end to end.
3. 3Set the defaults Build pinned dependencies, signed builds, SBOMs, ownership tags, resource limits and short-lived credentials into that path.
4. 4Keep it in Git Hold templates, infrastructure code, catalog entries and policies in open formats so the portal stays replaceable.
5. 5Run it as a product Give the platform a product manager, publish a roadmap, and let teams leave the path when it does not fit, with a clear cost to doing so.
6. 6Add agents with limits Give AI coding agents the same paths with scoped credentials, network allowlists, approved MCP servers and audit logs.
7. 7Review every quarter Compare the friction numbers and DORA's delivery measures with the baseline, and retire features nobody uses.

The case for platform engineering has shifted. The productivity argument rests on self-reported gains and a measured delivery dip that good design has to remove. The argument that holds up in 2026 is control: a shared path is where pinned dependencies, short-lived credentials, SBOMs, change records, cost tags and agent permissions become defaults instead of requests. The question to ask is which defaults you would enforce and what they would prevent, with the portal chosen afterward as a replaceable layer.

This is how we approach platform work in our cloud and DevOps engagements: measure the friction first, build the thinnest path that removes it, put security, cost and agent controls into that path as code in your repositories, and grow the platform only where the numbers show teams using it.