Consolidated platform engineering: who wins and who gets stuck
Actualizado: 2026-05-03
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.
Key takeaways
- Platforms that work were built on concrete painful problems, offer golden paths people want to follow, and the team manages them with product mindset.
- The most common failure has a name: empty Backstage portal. Technically correct, nobody visits it because it doesn’t solve any operational problem.
- Vanity metrics (catalog service count, migrated pipelines) have given way to outcome metrics (time to production, golden-path percentage).
- Backstage, Crossplane, and Port are the tools that won; Terraform and OpenTofu dominate the IaC layer.
- For fewer than 20 developers with a uniform stack, formal platform engineering is over-engineering.
What still stands
Internal platforms that survived and generate real value share several observable traits:
Built solving concrete painful problems. 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.
They 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. When the golden path is the fastest option — not the mandatory one — adoption comes naturally.
The platform team runs with product mindset. Measures real feature usage, talks to internal users, drops what nobody uses, evolves what they do. That 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
Empty Backstage portal. Companies installed Backstage, 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.
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. The “you don’t need to know this” promise broke at the first serious incident.
Setting up a platform without deciding which golden paths to support. If every team can deploy however they want, the platform gets reduced to lowest common denominator or, worse, additional cost nobody leverages. Getting teams aligned around a few supported patterns is politics, not tech.
Tools that won
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.
Crossplane has cemented its position as the declarative layer atop cloud providers with Kubernetes-native model. For teams already operating on Kubernetes, it exposes cloud resources as first-class types with access control and policies.
Port rose as commercial alternative to Backstage with more polished experience and less manual config. The Backstage vs. Port decision usually comes down to engineering time vs. license money.
For infrastructure-as-code: Terraform still dominates, OpenTofu gained ground after HashiCorp’s 2023 license controversy, Pulumi has a solid niche for teams preferring imperative code.
How to measure if the platform works
Vanity metrics from 2023-2024 have fallen into disrepute: service count, portal component count, migrated pipeline count. These measure activity, not value.
Metrics that actually indicate value in 2026:
- Time from new service request to production with adequate observability. If it dropped significantly from prior baseline, there’s value.
- Percentage of deployments following the golden path. If high (>80%), developers adopted voluntarily. If low (<40%), they’re bypassing it.
- Mean time to recovery (MTTR) after incident. If the platform helps with observability, alerts, and rollback, this drops.
- Development-team declared satisfaction measured with short quarterly surveys.
When to build a platform and when not to
Makes sense: companies with 100+ developers across multiple teams and diverse stacks. Cost of manually coordinating infrastructure scales quadratically with team count.
Doesn’t make sense: fewer than twenty developers with a relatively uniform stack. They need a good script set, a solid CI/CD pipeline, and clear conventions.
Between 20 and 100: gray zone where decision depends more on stack heterogeneity than absolute size. The common error is building ahead of time because a conference suggested it. If you can’t articulate which recurring ticket the platform eliminates in the first quarter, it’s not the time.
Conclusion
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. 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.
Last reviewed: 2026-04-06.
