Platform engineering cumple tres años como etiqueta popular a finales de 2025, y el ecosistema que creció a su alrededor está entrando en una fase más tranquila tras el entusiasmo inicial. Los equipos que se montaron con prisas durante 2022 y 2023, muchas veces renombrando equipos de DevOps o de infraestructura con la palabra de moda, han pasado por el filtro real de los últimos dos años. Algunos han producido valor claro y ahora son piezas centrales de sus organizaciones; otros se han disuelto silenciosamente o han quedado reducidos a una persona y un portal que nadie usa. Vale la pena revisar qué ha pasado, qué patrones diferencian los casos buenos de los malos, y cómo pensar hoy la disciplina cuando ya no es una promesa sino una práctica con cicatrices.
Qué prometía y qué entregó
La tesis original de platform engineering era razonable: los equipos de producto pierden demasiado tiempo resolviendo problemas de infraestructura que se repiten, las plataformas internas bien diseñadas pueden capturar ese trabajo común y ofrecerlo como servicio, y una organización que invierte en esa capa entrega más rápido y con menos fricción. Esta idea no era nueva, la habían articulado Google con su noción de platform teams y muchas otras empresas grandes, pero la popularización del término coincidió con Team Topologies del libro de Skelton y Pais, y con el auge de Backstage como portal de referencia.
La promesa que muchas empresas escucharon, sin embargo, fue distinta. Se tradujo en “montamos un equipo, instalamos Backstage, ponemos catálogos de servicios y plantillas, y el tiempo que los equipos pierden en infraestructura desaparece”. Esa versión simplificada llevó a muchos fracasos. Montar Backstage sin un equipo disciplinado detrás que mantenga plantillas, documentación y flujos es equivalente a montar un wiki: se llena de páginas que nadie actualiza y se convierte en un cementerio.
Los equipos que han entregado valor real en estos años comparten algunos patrones. Entendieron que una plataforma interna es producto, con gerente de producto, investigación de usuario y ciclos de iteración. Midieron adopción real de sus herramientas, no solo su existencia. Priorizaron caminos dorados sobre flexibilidad ilimitada, aceptando que un buen noventa por ciento cubre el caso común y que el diez por ciento restante no justifica la complejidad. Y mantuvieron equipos de producto como clientes respetados, no como usuarios cautivos.
Errores repetidos
Hay tres patrones de fracaso que se repitieron con frecuencia. El primero fue montar plataformas sin entender para quién. Equipos que escribieron plantillas genéricas basadas en su propia intuición de qué servicios se necesitan, sin hablar con los equipos de producto que iban a usarlas. Las plantillas salían, los equipos de producto las probaban una vez, encontraban que no encajaban con su realidad y volvían a construir infraestructura a mano. La plataforma se convertía en decoración.
El segundo fue confundir Backstage con plataforma. Backstage es un portal, una interfaz para descubrir servicios, plantillas y documentación. No resuelve los problemas por sí mismo, solo los organiza y presenta. Equipos que instalaron Backstage sin invertir en los flujos detrás terminaron con un portal vacío o desactualizado, donde la información era menos fiable que un documento compartido.
El tercero fue tratar la plataforma como proyecto y no como producto. Un proyecto tiene fecha de entrega y después pasa a mantenimiento; una plataforma necesita evolución continua mientras tenga usuarios. Cuando el proyecto se declaró terminado y el equipo se disolvió o se redujo drásticamente, la plataforma empezó a envejecer rápido y los equipos de producto empezaron a saltársela. En dos años había más esfuerzo salido de la plataforma que yendo hacia ella.
Qué separa los casos de éxito
Los equipos de platform engineering que están sanos a finales de 2025 tienen varios rasgos en común. El primero es que están cerca del negocio, no solo de la operación. Conocen qué prioridades tiene la empresa, entienden qué tipo de servicios se van a construir en los próximos meses, y preparan su plataforma para servir esas cargas antes de que lleguen los equipos de producto a pedirlas. Esta proactividad es la diferencia entre ser valorados como aceleradores o tolerados como burocracia.
El segundo es que miden. No adopción nominal sino adopción real: cuántos servicios usan la plantilla oficial, cuántos pipelines pasan por la infraestructura estándar, cuánta documentación está actualizada, qué tiempo tarda un equipo nuevo en desplegar su primer servicio. Estas métricas se revisan regularmente y se usan para decidir dónde invertir esfuerzo.
El tercero es que cuidan la experiencia del desarrollador como rasgo de producto. La documentación es buena, los errores son claros, los flujos son consistentes, los despliegues son predecibles. Un desarrollador que usa la plataforma no necesita escribir un ticket para cada duda; tiene lo que necesita a mano. Esto parece obvio pero es difícil, porque requiere pensar como cliente constantemente.
El papel cambiante de Backstage
Backstage cumplió cinco años como proyecto de Spotify liberado, y su evolución ilustra la madurez del espacio. Durante 2023 fue la herramienta de moda y todos los equipos de platform engineering lo instalaron. Durante 2024 empezaron las críticas: curva de aprendizaje empinada, plugins de calidad irregular, operación compleja. En 2025 Backstage sigue siendo relevante pero su posición es más madura: es una opción entre varias, no el estándar obligatorio.
Alternativas como Port o Cortex han ganado cuota de mercado ofreciendo experiencia más empaquetada a cambio de menos flexibilidad. Para equipos pequeños que no quieren operar Backstage, estas opciones son pragmáticas. Para equipos grandes con necesidades específicas, Backstage sigue siendo la opción de más recorrido, pero con el entendimiento claro de que requiere inversión continua.
El espacio de catálogos de servicios también se ha enriquecido con otras ideas: gráficos de dependencias generados automáticamente, integraciones con proveedores de nube para descubrir recursos existentes, vistas alineadas con responsabilidad de equipos. El catálogo ya no es solo una lista, es un grafo vivo sobre el que se construyen muchos otros flujos.
Qué mide realmente el valor
La métrica que mejor captura si una plataforma funciona es el tiempo entre que un equipo empieza a construir un servicio nuevo y lo tiene corriendo en producción con todos los estándares cumplidos. En plataformas sanas ese tiempo es de horas o de un día; en plataformas enfermas es de semanas porque el equipo descubre que la plantilla no aplica, que la infraestructura hay que solicitarla por ticket, que la observabilidad requiere configuración manual, y que la plataforma genera más trabajo que el que ahorra.
Otra métrica útil es la proporción de servicios en producción que siguen los estándares de la plataforma. Cuando esa proporción es alta, la plataforma es eficaz; cuando es baja, los equipos están eludiendo la plataforma por algún motivo y hay que entender cuál. A veces es fricción operativa, a veces es una decisión consciente de los equipos porque saben que la plataforma no cubre bien su caso. Ambas situaciones piden atención pero demandan intervenciones distintas.
Una tercera métrica es la satisfacción reportada por los equipos de producto. Encuestas regulares de cómo viven la plataforma, qué les frustra, qué les ha ayudado. Estas encuestas no sustituyen las métricas cuantitativas pero detectan señales tempranas de degradación que los números tardan en mostrar.
Cuándo compensa
La pregunta honesta para una organización es si tiene el tamaño y la complejidad que justifican invertir en platform engineering. Una empresa con diez ingenieros no necesita plataforma interna, la plataforma es el propio equipo; lo que necesita es buenas prácticas y algunos scripts compartidos. Una empresa con cien ingenieros empieza a beneficiarse si hay suficiente heterogeneidad de servicios; el retorno no es automático pero puede ser significativo si se hace bien. Una empresa con mil ingenieros probablemente no puede permitirse no tenerla, porque la pérdida de productividad sin plataforma unificada es enorme.
El error clásico es entrar antes de tiempo, con demasiada ambición y sin entender que la plataforma tiene que ganar a los equipos uno a uno, no imponerse por decreto. Cuando eso se intenta, lo que queda es una plataforma que los equipos esquivan y un equipo de plataforma frustrado porque nadie usa lo que construye.
Mi lectura
Platform engineering como disciplina ha madurado mucho en estos tres años, aunque el camino ha dejado más fracasos que éxitos visibles. Los equipos que entendieron que su función es construir producto para desarrolladores internos, con la misma disciplina que cualquier producto externo, han tenido éxito razonable. Los que confundieron la etiqueta con la solución, o pensaron que instalar herramientas equivalía a entregar valor, han aprendido la lección por la vía dura.
Para 2025 y adelante, la pregunta ya no es si tu organización necesita platform engineering sino cómo ejecutarlo bien. Las recetas están mejor documentadas, las trampas conocidas son más numerosas, y las herramientas disponibles son más variadas. Pero el trabajo sigue siendo difícil y cultural, y la parte técnica sigue siendo la más pequeña del reto. Quien entienda que la plataforma es un producto y lo opere como tal tiene una probabilidad razonable de éxito; quien piense que es un proyecto de infraestructura renombrado seguirá repitiendo los errores que dominaron la fase de expansión.
