In 2023, when Gartner declared platform engineering was the future, half the industry signed up. Through 2024 the first teams formed, the first internal portals got stood up, dozens of success stories with dubious metrics got published. Through 2025, reality caught up with fashion: many portals stayed empty, developers kept talking to infrastructure teams on Slack, and internal reports started questioning whether the effort had been worth it. In 2026, the dust has settled and you can clearly see which organizations won and which got stuck with a sunk cost.
What still stands
Internal platforms that survived and produce real value share several observable traits. First, they were built solving concrete and painful problems developers already reported: deploying a new app took three weeks with tickets across six teams; the platform cut it to fifteen minutes with one command. No narrative, measured reduction in time to production.
Second, successful platforms offer golden paths most teams want to be on. A developer creating a new service gets Docker template, CI pipeline, basic alerts, aggregated logs, TLS cert, and DNS entry in one step. They need to understand nothing inside. What’s behind is reasonable infrastructure, but the contract with development is about outcome, not components.
Third, the platform team runs with product mindset. Measures real feature usage, talks to internal users, drops what nobody uses, evolves what they do. That’s what separates the useful internal platform from the one nobody looks at: the first treats developers as customers who could switch providers; the second assumes they’ll use what’s offered because there’s no alternative.
What hasn’t worked
The most common 2026 failure has a name: empty Backstage portal. Companies installed Backstage, configured the catalog, added a dozen generic plugins, and then discovered real value was in integrating the portal with concrete internal flows, which nobody did. Result: a technically correct portal nobody visits because it solves no operational problem.
The second frequent failure is the platform-as-extra-layer-on-Kubernetes nobody understands. Teams that built their own abstraction atop Helm, company-specific YAML, and custom workflows ended up with a platform more complex than the underlying infrastructure. Developers had to half-learn Kubernetes to debug when something failed, and the “you don’t need to know this” promise broke at the first serious incident.
The third failure is setting up a platform without deciding which golden paths you’ll support. If every team can deploy however they want, with their own stack and workflows, the platform gets reduced to lowest common denominator or worse, to additional cost nobody leverages. Getting teams aligned around a few supported patterns is politics, not tech, and companies that didn’t solve the political part achieved nothing with tech.
Tools that won
In 2026, the platform engineering tools ecosystem has consolidated around several clear patterns. Backstage remains the reference for internal developer portal when integrated with real flows; the self-hostable fork is still alive in 2026 after the 2025 split from the commercial product and is the sensible choice for companies avoiding heavy external dependency.
Crossplane has cemented its position as the declarative layer atop cloud providers with Kubernetes-native model. For teams already operating on Kubernetes, Crossplane is a reasonable way to expose cloud resources as first-class types with access control and policies. It doesn’t replace Terraform in all cases but fits especially well when the org already has significant Kubernetes infrastructure and wants to extend that model across the board.
Port rose in popularity through 2024 and 2025 as commercial alternative to Backstage with more polished experience and less manual config. For companies with limited capacity to dedicate senior engineers to Backstage, Port is the pragmatic choice though with license cost. The decision between Backstage and Port usually comes down to whether you’d rather invest engineering time or license money.
For the infrastructure-as-code layer, Terraform still dominates in companies with mature stack, OpenTofu gained ground after HashiCorp’s 2023 license controversy, and Pulumi has a solid niche in teams preferring imperative code. Well-designed platforms abstract this layer so developers don’t touch it directly, but the platform team does need to master it.
How to measure if the platform works
Typical vanity metrics used through 2023 and 2024 have fallen into disrepute: service count in the catalog, portal component count, migrated pipeline count. These measure activity, not value, and a platform can have big numbers and produce nothing.
Metrics that actually indicate value in 2026 are four. Time from a developer requesting a new service to it being in production with adequate observability: if this dropped significantly from the prior baseline, there’s value. Percentage of deployments following the golden path: if high, developers adopted voluntarily; if low, they’re dodging. Mean time between incident and recovery: if the platform helps with observability, alerts, and rollback, this number drops. And finally, development-team declared satisfaction measured with short quarterly surveys.
The platform team measuring these four things and adjusting accordingly tends to produce a useful platform. The team measuring only activity and counting catalog components tends to produce visible work with no impact.
When to build a platform and when not to
There are organizations where platform engineering adds clear value and others where it’s more cost than benefit. The reasonable 2026 criterion is size and complexity. Companies with fewer than twenty developers and a relatively uniform stack don’t need a formal platform; they need a good script set, a solid CI/CD pipeline, and clear conventions. Standing up a platform here is over-engineering that diverts resources from product.
Companies with a hundred or more developers across multiple teams and diverse stacks benefit from a formal platform. Cost of manually coordinating infrastructure scales quadratically with team count, and a layer standardizing patterns and automating the repetitive amortizes quickly. Between twenty and a hundred developers is a gray zone where decision depends more on stack heterogeneity than absolute size.
The common error is trying to build a platform ahead of time because a conference or consultancy suggests it. The platform makes sense when it solves a painful problem you already have, not when you anticipate it with six years of runway. If you can’t articulate which recurring engineering ticket the platform kills in the first quarter, it’s probably not the time.
My reading
The balance of platform engineering in 2026 is that it’s a real discipline with real problems and reasonable solutions, but also a fashion that produced many poorly conceived projects. Organizations that understood it’s about managing an internal product with honest metrics, a dedicated team, and service mindset won a lot: reduce time to production, improve dev-team satisfaction, and achieve standardization without political friction. Those that just chased the buzzword got stuck with an empty portal and a bill.
The general lesson is familiar: value is in operational discipline, not the tool. Backstage, Crossplane, Port, or any combo are reasonable pieces; what determines success is whether the platform team runs as a product team, whether the org aligns around golden paths, and whether metrics measure value instead of activity. Where these three conditions exist, the platform accelerates. Where one is missing, the platform decorates. In 2026 you can tell one from the other clearly, and the time to pretend this was a trend is over.
