Jacar mascot — reading along A laptop whose eyes follow your cursor while you read.
Arquitectura Metodologías

Platform engineering: consolidation after the boom

Platform engineering: consolidation after the boom

Actualizado: 2026-05-03

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. 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.

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.
  • Three most frequent failures: building platforms without understanding for whom, confusing Backstage with platform, 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 all standards.
  • 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 done well; a thousand-engineer one probably can’t afford not to have one.

What it promised and what it delivered

The original thesis was reasonable: product teams waste too much time solving repeating infrastructure problems, well-designed internal platforms can capture that common work and offer it as a service. What many companies heard, however, was “we set up a team, install Backstage, add catalogs and templates, and the time teams waste on infrastructure disappears.” Running Backstage without a disciplined team behind it to maintain templates, documentation and flows is the same as running a wiki: it fills with pages nobody updates and becomes a graveyard.

Teams that delivered real value understood that an internal platform is product, with a product manager, user research and iteration cycles; they measured real adoption, not just existence; they prioritized golden paths over unlimited flexibility.

Repeated mistakes

Three failure patterns repeated frequently:

Building platforms without understanding for whom. Templates shipped, product teams tried them once, found they didn’t fit reality, and went back to building infrastructure by hand.

Confusing Backstage with platform. Backstage is a portal, an interface to discover services, templates and documentation. It doesn’t solve problems by itself.

Treating the platform as a project rather than a product. When the project was declared done and the team dissolved, the platform aged fast and product teams started going around it.

Backstage’s shifting role

In 2025 Backstage remains relevant but its position is more mature: it’s one option among several, not the mandatory standard. Alternatives like Port or Cortex gained market share by offering a more packaged experience in exchange for less flexibility.

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 all standards. 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 requires a ticket, observability needs manual config.

When it pays off

  • A ten-engineer company doesn’t need an internal platform.
  • A hundred-engineer company starts to benefit if there’s enough service heterogeneity.
  • A thousand-engineer company probably can’t afford not to have one.

The classical mistake is entering too early, with too much ambition and without understanding the platform has to win teams one by one, not impose itself by decree.

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.

Was this useful?
[Total: 0 · Average: 0]

Written by

CEO - Jacar Systems

Passionate about technology, cloud infrastructure and artificial intelligence. Writes about DevOps, AI, platforms and software from Madrid.