En 2023, cuando Gartner declaró que platform engineering era el futuro, medio sector se apuntó a la idea. Durante 2024 se formaron los primeros equipos, se montaron los primeros portales internos, se publicaron decenas de casos de éxito con métricas dudosas. Durante 2025, la realidad alcanzó a la moda: muchos portales quedaron vacíos, los desarrolladores siguieron hablando con los equipos de infraestructura por Slack y los informes internos empezaron a cuestionar si el esfuerzo había merecido la pena. En 2026, el polvo ya ha caído y se puede ver con claridad qué organizaciones ganaron y cuáles se quedaron con un coste hundido.
Lo que sigue en pie
Las plataformas internas que han sobrevivido y generan valor real comparten varias características observables. Primero, se construyeron resolviendo problemas concretos y dolorosos que los desarrolladores ya reportaban: desplegar una aplicación nueva tardaba tres semanas con tickets en seis equipos diferentes; la plataforma lo dejó en quince minutos con un comando. No hay relato, hay reducción medida de tiempo a producción.
Segundo, las plataformas con éxito ofrecen caminos dorados sobre los que la mayoría de equipos quieren estar. Un desarrollador que crea un servicio nuevo recibe template Docker, pipeline CI, alertas básicas, logs agregados, certificado TLS y entrada DNS en un solo paso. No necesita entender cómo funciona nada por dentro. Lo que hay por detrás es infraestructura razonable, pero el contrato con el equipo de desarrollo es sobre el resultado, no sobre los componentes.
Tercero, el equipo de plataforma funciona con mentalidad de producto. Mide uso real de sus features, habla con usuarios internos, descarta lo que nadie usa y evoluciona lo que sí. Esto es lo que separa la plataforma interna útil de la plataforma interna que nadie mira: la primera trata a los desarrolladores como clientes que pueden cambiar de proveedor; la segunda asume que van a usar lo que se les ofrezca porque no tienen alternativa.
Lo que no ha funcionado
El fracaso más común en 2026 tiene nombre: portal Backstage vacío. Empresas que instalaron Backstage, añadieron una decena de plugins genéricos y luego descubrieron que el valor real estaba en integrar el portal con flujos internos concretos, cosa que nadie hizo. Resultado: un portal técnicamente correcto que nadie visita.
El segundo fracaso frecuente es la plataforma como capa extra sobre Kubernetes que nadie entiende. Equipos que decidieron construir abstracción propia sobre Helm, YAML específico de empresa y workflows custom terminaron con una plataforma más compleja que la infraestructura subyacente. Los desarrolladores tenían que aprender Kubernetes a medias para depurar cuando algo fallaba, y la promesa de “no necesitas saber esto” se rompía en el primer incidente serio.
El tercer fracaso es montar plataforma sin haber decidido qué caminos dorados vas a soportar. Si cada equipo puede desplegar como quiera, con stack propio y workflows propios, la plataforma queda reducida a mínimo común denominador o peor, a coste adicional que nadie aprovecha. Lograr que los equipos se alineen alrededor de unos pocos patrones soportados es política, no tecnología, y las empresas que no resolvieron la parte política no lograron nada con tecnología.
Herramientas que han ganado
En 2026, el ecosistema se ha consolidado alrededor de varios patrones claros. Backstage sigue siendo la referencia para portal interno de desarrollador cuando lo integras con flujos reales; el fork autoalojable sigue vivo tras la bifurcación de 2025 respecto al producto comercial y es la opción sensata para empresas que no quieren dependencia externa fuerte.
Crossplane ha consolidado su posición como capa declarativa sobre proveedores cloud con modelo Kubernetes-nativo. Para equipos que ya operan en Kubernetes, expone recursos cloud como tipos de primera clase con control de acceso y políticas. No sustituye Terraform en todos los casos, pero encaja bien cuando la organización ya tiene infraestructura Kubernetes significativa.
Port ha subido en popularidad como alternativa comercial a Backstage con experiencia más pulida y menos configuración manual. La decisión entre Backstage y Port suele reducirse a si prefieres invertir tiempo de ingeniería o dinero en licencia. Para infraestructura como código, Terraform sigue dominante, OpenTofu ha ganado terreno tras la controversia de licencia de HashiCorp en 2023 y Pulumi tiene nicho sólido en equipos que prefieren código imperativo.
Cómo medir si la plataforma funciona
Las métricas de vanidad típicas que se usaron durante 2023 y 2024 han caído en descrédito: número de servicios en el catálogo, número de componentes del portal, número de pipelines migrados. Estas métricas no miden valor, miden actividad, y una plataforma puede tener cifras grandes y no aportar nada.
Las métricas que de verdad indican valor en 2026 son cuatro. Tiempo desde que un desarrollador solicita servicio nuevo hasta que está en producción con observabilidad adecuada: si esto ha bajado significativamente frente al baseline previo, hay valor. Porcentaje de despliegues que siguen el camino dorado: si es alto, los desarrolladores han adoptado la plataforma voluntariamente; si es bajo, están esquivándola. Tiempo medio entre incidente y recuperación: si la plataforma ayuda con observabilidad, alertas y rollback, este número baja. Y por último, satisfacción declarada del equipo de desarrollo medida con encuestas cortas trimestrales.
El equipo de plataforma que mide estas cuatro cosas y ajusta en consecuencia tiende a producir plataforma útil. El equipo que mide solo activdad y cuenta componentes del catálogo tiende a producir trabajo visible pero sin impacto.
Cuándo sí montar plataforma y cuándo no
El criterio razonable en 2026 es el tamaño y la complejidad. Empresas con menos de veinte desarrolladores y un stack relativamente uniforme no necesitan plataforma formal; lo que necesitan es un buen conjunto de scripts, una pipeline CI/CD sólida y convenciones claras.
Empresas con cien o más desarrolladores repartidos en múltiples equipos y stacks diversos sí se benefician. El coste de coordinar la infraestructura manualmente escala cuadráticamente con el número de equipos, y una capa que estandariza patrones amortiza rápido. Entre veinte y cien hay zona gris donde la decisión depende más de la heterogeneidad del stack que del tamaño absoluto. El error común es montar plataforma antes de tiempo porque una conferencia lo sugiere: si no puedes articular qué ticket recurrente mata la plataforma en el primer trimestre, no es el momento.
Mi lectura
El balance de platform engineering en 2026 es que es una disciplina real con problemas reales y soluciones razonables, pero también es una moda que produjo muchos proyectos mal concebidos. Las organizaciones que entendieron que se trata de gestionar producto interno con métricas honestas, equipo dedicado y mentalidad de servicio ganaron mucho: reducen tiempo a producción, mejoran satisfacción del equipo de desarrollo y logran estandarización sin fricción política. Las que se limitaron a seguir la palabra de moda se quedaron con portal vacío y factura.
La lección general es familiar: el valor está en la disciplina operativa, no en la herramienta. Backstage, Crossplane, Port o cualquier combinación son piezas razonables; lo que determina el éxito es si el equipo de plataforma funciona como equipo de producto, si la organización está dispuesta a alinearse alrededor de caminos dorados y si las métricas miden valor y no actividad. Donde estas tres condiciones están presentes, la plataforma acelera. Donde falta una, la plataforma decora. En 2026 se puede distinguir entre una y otra con claridad, y el tiempo para fingir que esto era tendencia ya pasó.
