Here is a number that would have sounded absurd five years ago: by 2025, roughly nine in ten of the organisations DORA researched were running some kind of internal platform. Platform engineering stopped being a conference talking point and became the default way large engineering departments assemble their tooling. So the interesting question for 2026 is no longer whether companies build internal developer platforms — plenty do, reluctantly or otherwise. The question is whether anybody actually operates the thing well once the launch party ends. That second act has picked up a name of its own, PlatformOps, and if you follow AI and automation trends it deserves a spot on your reading list, because platforms are precisely where AI assistance is landing first.

If you want one reference to keep open while you read this, xOps School’s PlatformOps guide in the Ops Atlas covers the definitions, the architecture and the vocabulary in more depth than a trend piece can. Consider this the friendly overview: what changed, what broke, and what looks durable.

PlatformOps Is Now the Default Ambition

The first change is one of posture. For years, “we’re building a platform” meant a project: a budget line, a deadline, a launch, then silence. The operating mindset treats the platform the way a product manager treats a product. There are service levels attached to each capability. There are support tiers, so people know who to call. There are upgrades, and — this is the part most organisations skip — there are deprecations, with dates and humans assigned to help you move off whatever is being retired.

The CNCF has been consistent about the philosophy underneath: platforms should be optional and composable. Optional is the uncomfortable word. A platform with no org-chart power over its users has to earn every adoption, which is exactly why product thinking fits it so well. In DORA’s framing, platform engineering is sociotechnical — the shared tooling and the human arrangements around it stand or fall together, and no purchase order substitutes for either. Thoughtworks has warned, bluntly, that renaming an operations team to “platform team” without changing how work flows through it is a label swap, not a transformation.

The Adoption Curve Has a Dip Built In

Now for the finding that surprises executives: DORA also found that platforms can lower both throughput and stability when they are managed badly. A platform is not a dial you turn and watch metrics rise. The usual shape of the transition is a J-curve — things get slower and messier while teams migrate, then improve past the old baseline once the shared capabilities settle.

Which metrics? Practitioners watch time to first deploy for a newcomer service, template coverage across the estate, how often teams actually stay on the paved routes, service-level attainment, and less glamorous things like how quickly deprecated stuff is actually retired. None of these move without deliberate operation. That is the whole argument for treating the platform as something you run rather than something you ship.

Rumour-Driven Development Is the Real Villain

Spotify’s internal-origin story for its platform work is worth retelling, because the failure it addresses is so ordinary. Teams kept rebuilding near-identical things — another deploy pipeline here, another player-debug tool there — mostly because nobody knew something suitable already existed. Spotify’s engineers gave this a great name: rumour-driven development, where the discovery mechanism for internal software is hallway chatter.

The fix is not a prettier homepage. It is running the platform as an internal product whose adoption must be pulled — teams choose it because it is genuinely the easier way. Jan Bottcher’s framing gets quoted a lot for good reason: an internal product has to be compelling to use, or it will not be used. Mandates produce compliance, and compliance produces shadow tooling six months later.

How the Tooling Grew Up

The other reason the trend has legs is that the building blocks matured. A rough map of the pieces most stacks draw on:

• Backstage — Spotify’s open-source portal framework, a CNCF incubating project since March 2022, shipping monthly releases; its catalog entities and Software Templates are what most developer portals are actually made of.
• Crossplane — control-plane tooling for composing cloud infrastructure; its CNCF journey completed with graduation in October 2025.
• Argo CD and Flux — the GitOps engines that keep environments reconciled with whatever the platform declares.
• Prometheus and OpenTelemetry — the metrics and traces that let platform teams publish honest service levels instead of vibes.
• OPA and Kyverno — policy engines that turn “the platform is safe” from a promise into an enforced rule.

Underneath those parts, most reference architectures describe three layers: the experiences users touch (portal, CLI, APIs, templates), the platform core where orchestration and policy live, and the providers below — cloud accounts, clusters, CI systems. The CNCF’s working definition of a platform is an integrated collection of capabilities, arranged around what the users need rather than what the vendor sells. It sounds obvious written down. Very few enterprise tooling catalogues are arranged that way.

Even Vendors Kill Their Platforms

Here is the part of the 2026 story nobody puts in a pitch deck. AWS Proton — a managed platform product, launched with keynotes — had its support end on 7 October 2026. Azure Deployment Environments is scheduled for retirement on 22 February 2027. These were not obscure side projects; they were first-party portal products from two of the biggest vendors in the market, and both died.

The lesson is not “never buy tools”. It is about where you concentrate your irreducible complexity. If the distinctively yours part of the platform — the golden paths, the templates, the catalog data, the relationships with teams — is built on composable, swappable parts, then a vendor departure is a migration. If your whole platform is one vendor’s portal, that same departure is an extinction event. PlatformOps, practiced seriously, keeps the experience layer replaceable.

PlatformOps Meets AIOps

Now the part this site’s readers actually came for. Why should AI watchers care about internal platforms? Three convergences stand out.

First, golden paths are the rails that AI-assisted development needs. An agent that proposes code changes is only safe when the surrounding pipeline can test, review and roll back those changes reliably. That machinery is exactly what a platform provides. Teams wondering where AI is likely to take software development next keep arriving at the same bottleneck: not model quality, but the operational rails around the model.

Second, the platform catalog is context. When a developer asks an assistant “who consumes this service and what breaks if I change its contract?”, the answer lives in ownership and dependency data — the same data a well-run platform maintains anyway. Garbage catalog, garbage answer.

Third, the trust boundary runs through the platform core. Orchestration and policy sit where provider credentials live, and as agents start triggering deployments instead of humans, the policy layer is what stops an enthusiastic automation from doing something expensive. None of this is hypothetical; the observability signals that AIOps products consume are the same Prometheus and OpenTelemetry streams a platform emits. There is a useful analogy in the way digital twins mirror physical systems: the catalog mirrors the software estate, and its quality decides whether reasoning about that estate is worth anything. The same principle shows up in how AI improves business decision making — the model is rarely the weak point; the data plumbing is.

What to Watch From Here

Three things seem likely to define the next stretch of this trend. Deprecation pace will become a respected health signal — anyone can launch capabilities; retiring them gracefully is the mature behaviour. Retention and satisfaction will matter more than raw adoption counts, because forced usage inflates the latter. And the boundary between application teams and platform teams will stay sharpened: app teams keep the pager for their services, platform teams for platform components. Blurring that line is how 2 a.m. incidents get owned by nobody.

The overall trajectory is easy to summarise. Building platforms became normal; operating them as products is the current frontier; and the organisations that get the operating half right are the ones whose AI investments actually compound. Debates about how AI will impact software development tend to assume the plumbing sorts itself out. It does not — somebody has to run it, fund it and occasionally switch it off. Watch the deprecation notes, not the launch posts.