Platform engineering in 2026: when an internal platform pays off

What the data on platforms actually say

According to the DORA definition, platform engineering is a sociotechnical discipline: a team builds shared tools, services and “golden paths” that let other teams get an application safely into production without having to understand the entire infrastructure. The key word is sociotechnical. Most failures do not have a technical cause.

The most frequently cited numbers come from the DORA 2024 report. Users of an internal platform were 8% more productive, their teams performed 10% better, and the organization's software delivery and operational performance came out 6% higher. The same report, however, measured roughly 8% lower throughput and 14% lower change stability for those same respondents compared with those who do not use a platform.

The second half of that sentence is usually left out of presentations to leadership. Yet DORA does not consider it marginal: in its summary of key findings, alongside the productivity benefit, it explicitly mentions “warning signs” for software delivery performance, and in the chapter on platforms it recommends prioritizing features that give developers independence.

Why might a platform slow delivery down? The report itself offers several hypotheses and considers none of them confirmed. A platform adds more mechanisms a change has to pass through and more handoffs between systems. It gives teams the confidence to attempt riskier changes, or its automated quality checks are not good enough. Or companies introduce it precisely where delivery is already struggling. In every case the same thing helps: self-service. According to DORA, it adds another 5% of productivity when a developer can complete a task without the platform team's involvement.

2026: the platform as a prerequisite for AI

The DORA 2025 report, based on responses from almost 5,000 industry professionals, moved the debate elsewhere. 90% of respondents use AI at work and 90% of organizations have at least one internal platform; according to DORA, 76% of them have a dedicated platform team. The main conclusion: AI acts as an amplifier. Where the platform is high-quality, AI adoption has a strong positive effect on organizational performance. Where it is weak, the effect is negligible.

The same edition confirms that AI continues to have a negative relationship with delivery stability. More changes, faster, means more opportunities to break something if automated tests, fast feedback and guardrails in the pipeline are missing. Those guardrails are exactly what a platform should provide. Deployment in the AI era is covered in more detail in our article on deployment automation.

Vendor surveys point in the same direction, though they should be read with an awareness of who pays for them. Perforce (Puppet) published results in July 2026 from 820 respondents: 66% of organizations use AI in infrastructure workflows, but only 31% report fully autonomous AI. Among organizations with a mature internal developer platform (IDP), the figure is 44%.

At the spring KubeCon in Amsterdam, CNCF and SlashData presented a Technology Radar on 24 March 2026, according to which 35% of organizations integrate AI workloads in a hybrid way – adding specialized tools to their existing platform rather than building a new one. According to a recap of BackstageCon (which began on 23 March) and KubeCon, the Backstage maintainers presented work-in-progress MCP support and an “AI-native” direction for the portal.

When a platform pays off and when it is an expensive toy

A platform is an investment with fixed costs: the people who build and maintain it are not delivering features to customers. It pays back only when it removes repetitive work for enough teams. The decision therefore depends not on the trend but on a few measurable signals.

The last row is the most common reason platform initiatives fail. A portal on top of disorganised infrastructure solves nothing; it just adds one more thing to maintain. If the foundations are not in place, start there – see our article on infrastructure chaos before adopting AI.

The counterargument is legitimate: a small company with a single product can get by with a decent pipeline, a shared Terraform module and documentation. That is not a failure; it is a right-sized solution.

A minimum viable platform for 20–100 developers

The CNCF Platforms White Paper defines a platform as an integrated collection of capabilities offered according to the needs of its users, and points out that a very simple “platform” can even be a wiki page with links to standard procedures. Among its recommendations, DORA says the same thing in different words: start with a minimum viable platform for the most common workflows.

For a company of this size, in practice that means four building blocks:

• One to three golden paths. A repository template for the most common type of service: an application skeleton, a Dockerfile, a pipeline with tests and security checks, deployment manifests, a basic dashboard and alerts. What such a pipeline should look like is described on our Ideal Pipeline page.
• Self-service environments and resources. A database, a queue or a namespace is created by a pull request to a repository of vetted modules, not by a ticket.
• Guardrails in code. Policies (e.g. OPA), limits and mandatory checks are part of the path, so the secure option is also the easiest one.
• Documentation and ownership records. Who owns the service, where it runs, how it is deployed. A file in the repository and a generated overview are enough.

Ownership records do not have to wait for a portal. A descriptor file in the format Backstage uses can be introduced straight away, and the portal built on top of it later:

apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: invoicing-api
  description: REST API for issuing invoices
  annotations:
    github.com/project-slug: company/invoicing-api
spec:
  type: service
  lifecycle: production
  owner: team-finance
  system: invoicing

Who should do it

As a rough guide: a small team with a clear mandate, in which at least one person does product work – talks to developers, sets priorities, says no. It does not have to be a dedicated role. A Platform Engineering community survey of 518 practitioners reports that only 21.6% of organizations have a dedicated platform product manager and 25.4% have no product thinking at all. At 13.1%, the platform relies on voluntary, unfunded work, which corresponds to the lowest maturity level.

Backstage, alternatives and whether you need a portal at all

Backstage is an open-source framework for developer portals, originally from Spotify and now a CNCF project. In the March CNCF and SlashData radar it was placed, together with Helm and kro, in the “adopt” category for application delivery. That makes it the default choice – and also the most common trap.

Backstage is not a finished product but a framework. It requires TypeScript development, plugin maintenance and regular upgrades. For a company with hundreds of developers, that is a reasonable price for flexibility. For a company with fifty developers, running the portal can consume capacity that should have gone into golden paths.

What matters is not the tool but the order. A portal is an interface to the platform, not the platform itself. If there is no working automation behind the “create service” button, you end up with a pretty signpost nobody opens.

The platform as a product: metrics and a maturity model

The CNCF Platform Engineering Maturity Model assesses five aspects – investment, adoption, interfaces, operations and measurement – across four levels, from “provisional” to “optimizing”. It is useful mainly as a mirror. For adoption, it distinguishes between a state where teams are pushed onto the platform from outside (“extrinsic push”) and one where they want it themselves (“intrinsic pull”).

According to the Platform Engineering survey mentioned above, 36.6% of organizations still depend on a top-down mandate and only 28.2% report that users adopt the platform for its own value. Measurement is even more telling: 29.6% of organizations do not measure platform success at all, and 24.2% do not know whether their metrics have improved.

A platform whose benefit nobody knows is the first item on the list when budgets are cut. And very little is needed:

DORA adds one concrete pointer for priorities: among its recommendations for platform teams, it highlights clear feedback on the outcome of a task. After triggering a pipeline or requesting an environment, a developer should immediately see what happened and, if it failed, why.

Anti-patterns that reliably bury a platform

On its platform engineering page, DORA names five typical traps. Each one can be recognized by a specific symptom:

• “Build it and they will come.” The platform is created without talking to users. Symptom: the roadmap lists technologies, not developer problems.
• Ivory tower. Standards come from above with no possibility of exceptions. Symptom: teams build shadow pipelines.
• Ticket-ops. The platform team is a renamed operations team that processes requests. Symptom: the ticket queue grows with the number of developers.
• Big bang. A year of work on the perfect platform before the first user. Symptom: no team uses it in production after the first quarter.
• One size fits all. The same path for a web service, a data pipeline and an ML model. Symptom: the most exceptions are requested by the teams with the highest added value.

To this comes one specific to 2026: building a second, separate platform for AI. The Platform Engineering survey reports that 55.9% of organizations already run more than one platform. Each additional one means another set of guardrails to maintain – and an AI agent that generates infrastructure needs the same policies as a human.

What to do on Monday

Postpone decisions about a portal, Backstage and growing the team until at least two teams use the first golden path voluntarily. Until then, it would be an investment in an interface to something that does not yet exist.

Key takeaways

• The benefit is not guaranteed. DORA 2024 measured higher productivity (8%) for platforms, but also lower throughput (8%) and change stability (14%). Without measurement, you cannot tell which side your company is on.
• AI raises the stakes. According to DORA 2025, platform quality determines whether AI adoption shows up in organizational performance.
• Start thin. One to three golden paths, self-service via Git and guardrails in code. The portal comes afterwards.
• The platform is a product. It needs an owner, user research and metrics; yet almost 30% of organizations do not measure platform success at all.
• Adoption figures differ several-fold. From 28% to 76% of organizations with a dedicated team, depending on the source. Decide based on your own bottlenecks, not the trend.
• For small companies with a single stack, a good pipeline, shared modules and documentation are a sufficient solution.