Consolidated platform engineering: who wins and who gets stuck
Table of contents
- Key takeaways
- What still stands
- What hasn't worked
- Tools that won
- How to measure if the platform works
- When to build a platform and when not to
- Conclusion
- Frequently asked questions
- How many developers do you need before platform engineering makes sense?
- How do I know whether my internal platform is actually working?
- Why do so many Backstage portals end up empty?
- Sources
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.
The pattern repeated: empty portals, developers still talking to infrastructure teams on Slack, and internal reports starting to question 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 three 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 teams choose on their own. 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, and its CNCF project page[1] confirms it as the sector’s de facto standard. 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. In November 2025 it reached CNCF graduation[2], the foundation’s highest maturity tier, alongside projects like Kubernetes and Prometheus. 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. Per its own comparison against Backstage[3] (a vendor source, not neutral), the decision comes down to a trade between engineering time and vs. license money.
For infrastructure-as-code, Terraform still dominates. OpenTofu gained ground after HashiCorp’s 2023 license controversy, when the Linux Foundation accepted the fork under the OpenTofu name[4]. And 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 from the prior baseline, there’s value; if it stayed flat, the platform is not helping there.
-
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. That lines up with the Gartner forecast that an analysis by Roadie cites[5]: 80% of large software engineering organizations would have their own platform team by 2026, up from 45% in 2022.
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 it’s also a fashion that produced poorly conceived projects: empty portals and bills with nothing behind them. 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. Success comes down to three things: 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.
Frequently asked questions
How many developers do you need before platform engineering makes sense?
It makes sense from about 100 developers spread across multiple teams and diverse stacks, because coordinating infrastructure manually scales quadratically with team count. With fewer than twenty developers on a uniform stack it is over-engineering: a good script set, a solid CI/CD pipeline, and clear conventions are enough. Between 20 and 100 is a gray zone; if you cannot articulate which recurring ticket the platform eliminates in the first quarter, it is not the time.
How do I know whether my internal platform is actually working?
Use four outcome metrics rather than activity counts: time from a new service request to production with adequate observability. Percentage of deployments following the golden path: above 80% means voluntary adoption, below 40% means developers are bypassing it. MTTR from incident to recovery, and development-team satisfaction measured with short quarterly surveys. Counting catalog services or migrated pipelines measures visible work, not impact.
Why do so many Backstage portals end up empty?
Because Backstage was installed with a dozen generic plugins and never integrated with concrete internal flows, which is where the real value was. The result is a technically correct portal nobody visits because it solves no operational problem. Backstage remains the reference for an internal developer portal when integrated with real flows. Its self-hostable fork is still alive after the 2025 split from the commercial product, and Port is the commercial alternative with less manual configuration.
