Updated: 2026-07-07

Platform engineering turns three years old as a popular label in late 2025, and the ecosystem that grew around it is entering a calmer phase after the initial hype. Teams set up in a hurry during 2022 and 2023 have gone through the real filter of the last two years. Some delivered clear value and are now central pieces of their organizations; others dissolved quietly or shrank to one person and a portal no one uses. It’s worth reviewing what happened, which patterns separate the good cases from the bad ones, and how to think about the discipline today, now that it’s no longer a promise but a practice with scars.

Key takeaways

  • Platform engineering teams that delivered real value understood that an internal platform is a product, with a product manager, user research, and iteration cycles.

  • The three most frequent mistakes: building platforms without understanding for whom, confusing Backstage with the platform itself, and treating the platform as a project with a delivery date instead of a product with continuous evolution.

  • The metric that best captures whether a platform works is the time between a team starting to build a new service and having it running in production meeting every standard.

  • Backstage remains relevant in 2025 but its position is more mature: it’s one option among several, not the mandatory standard.

  • A ten-engineer company doesn’t need an internal platform; a hundred-engineer one starts to benefit if it’s done well; a thousand-engineer one probably can’t afford not to have one.

What it promised and what it delivered

The original thesis behind platform engineering was reasonable: product teams waste too much time solving infrastructure problems that repeat across the organization, well-designed internal platforms can capture that common work and offer it as a service, and an organization that invests in that layer ships faster and with less friction.

The promise many companies actually heard, though, was different. It got translated into "we set up a team, install Backstage, add service catalogs and templates, and the time teams waste on infrastructure disappears." That simplified version led to a lot of failures. Running Backstage without a disciplined team behind it to maintain templates, documentation, and workflows is the same as running a wiki: it fills up with pages nobody updates and turns into a graveyard.

Teams that delivered real value share a few patterns:

  • They understood that an internal platform is a product, with a product manager, user research, and iteration cycles.

  • They measured real adoption of their tools, not just their existence.

  • They prioritized golden paths over unlimited flexibility, accepting that a good 90 percent covers the common case.

  • They kept product teams as respected customers, not captive users.

Repeated mistakes

Three failure patterns repeated often:

The first was building platforms without understanding for whom. Teams wrote generic templates based on their own intuition about what services were needed, without talking to the product teams who were meant to use them. The templates shipped, product teams tried them once, found they didn’t fit their reality, and went back to building infrastructure by hand. The platform turned into decoration.

The second was confusing Backstage with the platform. Backstage is a portal, an interface for discovering services, templates, and documentation. It doesn’t solve problems by itself, it only organizes and presents them. Teams that installed Backstage without investing in the workflows behind it ended up with an empty or stale portal, where the information was less reliable than a shared document.

The third was treating the platform as a project instead of a product. A project has a delivery date and then moves into maintenance; a platform needs continuous evolution as long as it has users. When the project was declared done and the team was dissolved or cut drastically, the platform started aging fast and product teams started skipping it.

What sets the success cases apart

Platform engineering teams that are healthy in late 2025 share several traits:

  • They stay close to the business, not just to operations. They know what priorities the company has and prepare their platform to serve those workloads before product teams show up asking for them.

  • They measure: how many services use the official template, how many pipelines run through the standard infrastructure, how long it takes a new team to deploy its first service.

  • They treat developer experience as a product trait: good documentation, clear errors, consistent workflows, predictable deployments.

Backstage’s shifting role

Backstage[1] turned five as a project released by Spotify. Through 2023 it was the tool of the moment and every platform engineering team installed it. During 2024 the criticism started: steep learning curve, uneven plugin quality, complex operation. In 2025 Backstage remains relevant but its position is more mature: it’s one option among several, not the mandatory standard. The detailed comparison lives in Backstage, Port and Cortex: Three Paths to the IDP.

Alternatives like Port[2] or Cortex[3] gained market share by offering a more packaged experience in exchange for less flexibility. For small teams that don’t want to operate Backstage, these options are pragmatic. For large teams with specific needs, Backstage remains the option with the longest runway, but with the clear understanding that it requires continuous investment.

What actually measures value

The metric that best captures whether a platform works is the time between a team starting to build a new service and having it running in production meeting every standard. On healthy platforms that time is hours or a day; on sick platforms it’s weeks, because the team discovers the template doesn’t apply, infrastructure has to be requested through a ticket, and observability needs manual configuration.

Another useful metric is the share of production services that follow the platform’s standards. When that share is high, the platform is effective; when it’s low, teams are routing around the platform for some reason. This same principle of measuring real adoption applies to other engineering tools, as described in AI testing: the determinism problem: it isn’t enough for the tool to exist, it has to be used and produce results.

A third metric is satisfaction reported by product teams. Regular surveys catch early degradation signals that the numbers take longer to show.

When it pays off

The honest question for any organization is whether it has the size and complexity that justify investing in platform engineering:

  • A company with ten engineers doesn’t need an internal platform, the platform is the team itself; what it needs is good practices and a few shared scripts.

  • A company with a hundred engineers starts to benefit if there’s enough service heterogeneity; the payoff isn’t automatic, but it can be significant if done well.

  • A company with a thousand engineers probably can’t afford not to have one, because the productivity loss without a unified platform is enormous.

The classic mistake is entering too early, with too much ambition and without understanding that the platform has to win teams over one by one, not impose itself by decree. When that gets tried anyway, what’s left is a platform teams route around and a frustrated platform team wondering why nobody uses what it builds.

My take

Platform engineering as a discipline has matured a lot over these three years, even though the road has left more failures than visible successes. Teams that understood their job is to build product for internal developers, with the same discipline as any external product, have had reasonable success. Those who confused the label with the solution, or thought installing tools was the same as delivering value, learned the lesson the hard way.

For 2025 and beyond, the question is no longer whether your organization needs platform engineering but how to execute it well. The playbooks are better documented, the known traps are more numerous, and the available tools are more varied. But the work is still hard and cultural, and the technical part remains the smallest piece of the challenge.

Conclusion

Those who understand the platform is a product and operate it as such have a reasonable success probability; those who think it’s a renamed infrastructure project will keep repeating the mistakes that defined the expansion phase.

This article is also available in Spanish: Platform engineering: consolidación tras el boom.

Sources

  1. Backstage
  2. Port
  3. Cortex