Plataforma interna de desarrollo (IDP): construir o comprar

La respuesta corta: la mayoría de los equipos de menos de 50 ingenieros deberían comprar

"¿Construir o comprar?" es la forma equivocada de hacer la pregunta. El encuadre binario borra la variable que decide el resultado: el costo de mantenimiento continuo. El análisis típico compara el costo inicial de construir contra el costo de licencia de un producto, concluye que construir sale más barato al principio y preserva flexibilidad, y omite por completo lo que cuesta sostener la plataforma año tras año.

Por eso, como punto de partida:

• Por debajo de unos 50 ingenieros, comprar un producto establecido casi siempre gana. La capacidad de ingeniería que haría falta para construir compite de frente con el trabajo de fundación de plataforma que todavía falta a esa escala.
• La mayoría de los equipos que construyen un portal a medida subestiman el costo de mantenimiento por un factor de tres.
• La vía híbrida (comprar una base como Port o Backstage y extenderla con disciplina) es a menudo la respuesta correcta, y rara vez la que los equipos eligen por su cuenta.

La decisión sobre una IDP se suele tomar antes de definir qué tiene que hacer el portal, qué costará mantenerlo y cómo se ve el éxito un año después del lanzamiento. Este marco existe para que la primera decisión sea la correcta. Es parte de nuestra guía de consultoría de platform engineering en español.

¿Qué es una plataforma interna de desarrollo?

Una plataforma interna de desarrollo (IDP, internal developer platform) es la capa self-service que un equipo de platform engineering construye sobre la infraestructura para que los equipos de aplicación puedan provisionar entornos, desplegar servicios, gestionar secretos y acceder a observabilidad sin abrir un ticket ni preguntarle a un ingeniero senior cómo se hace.

La palabra que importa es self-service. Una IDP no es un sitio de documentación ni un runbook. Es una capa ejecutable y opinada que absorbe las decisiones que los desarrolladores no necesitan tomar de a uno (versión del runtime, estrategia de despliegue, valores de seguridad por defecto, configuración de observabilidad) y expone el resto como una interfaz acotada.

Matthew Skelton y Manuel Pais lo definieron con precisión en Team Topologies: el equipo de plataforma construye una plataforma que reduce la carga cognitiva de los equipos alineados al flujo. La vara es concreta. Un desarrollador que usa la IDP debería poder ir del commit al servicio corriendo en producción sin entender la red de Kubernetes, los tokens de Vault ni el state locking de Terraform. Si todavía necesita entender esa infraestructura para trabajar, la IDP transfirió su complejidad en lugar de absorberla.

Qué NO es una IDP

• No es solo un portal. Un portal es una UI. La IDP son las capacidades que están detrás. Muchos equipos construyen Backstage primero y llaman IDP al resultado: un frontend con poco atrás. El portal es lo último que se construye, no lo primero.
• No es Backstage por defecto. Backstage es un framework específico de Spotify, liberado como open source en 2020, que aporta un catálogo de servicios y un sistema de plugins. Es una opción para la capa frontend, no la IDP en sí. Equipos de menos de 50 ingenieros suelen estar mejor servidos por una interfaz self-service simple que por un despliegue completo de Backstage.
• No es un proyecto de una sola persona. Una IDP es un producto con clientes, roadmap, SLA y ciclo de feedback. Necesita un equipo de plataforma con el mandato de volverla el camino por defecto, no un experimento al margen sin respaldo de liderazgo.

Por qué "construir vs comprar" falla a los líderes de ingeniería

El encuadre seduce porque reduce una decisión compleja a un binario. Falla de dos maneras predecibles.

Primero, la estimación inicial de construir es consistentemente baja. Armar un catálogo de servicios que funcione, un sistema de plantillas, integración con documentación y control de acceso toma más de los tres a seis meses que se suelen presupuestar. Seis a doce meses es más realista para una primera implementación que los desarrolladores realmente usen.

Segundo, y más determinante: el costo de mantenimiento casi nunca se modela. Un portal a medida exige tiempo de ingeniería continuo para sostener integraciones a medida que las herramientas de base evolucionan, actualizar el sistema de plantillas cuando se agregan tipos de servicio, arreglar la sincronización del catálogo cuando cambia la topología y mantenerlo operativo. No es un costo único: es un impuesto permanente sobre el equipo que es dueño del portal.

El costo total de propiedad: los cuatro componentes que se omiten

Un modelo de TCO completo para una IDP tiene cuatro componentes, y conviene medirlos en capacidad de ingeniería (FTE y meses-ingeniero), no en una sola cifra de licencia:

1. Costo inicial de construcción o configuración. El orden es consistente: el producto comercial tiene el costo inicial más bajo, la construcción a medida el más alto, y Backstage queda en el medio según cuánta personalización de plugins haga falta.
2. Costo de mantenimiento continuo. Acá es donde la construcción a medida diverge. Estimaciones realistas: un producto comercial consume del 5 al 10% del tiempo de un ingeniero; Backstage, entre 0,5 y 1,5 FTE según la cantidad de plugins y personalizaciones; un build a medida, de 1 a 2 FTE de forma indefinida.
3. Costo de desarrollo de integraciones. El valor del portal es proporcional a su profundidad de integración. Los productos comerciales traen integraciones prearmadas para las herramientas comunes; la construcción a medida levanta cada una desde cero.
4. Costo de oportunidad. Cada hora-ingeniero gastada en construir y mantener el portal es una hora que no se invirtió en capacidades de plataforma que mejoran directamente la experiencia del desarrollador.

Cuando se modelan los cuatro juntos, la construcción a medida rara vez sale más barata en un horizonte de tres años, y casi nunca en cinco. La ventaja inicial se disuelve entre los 12 y 18 meses una vez que se incluye el mantenimiento.

Qué cambia con 10, 50 y 200 ingenieros

La decisión correcta no es la misma a cada escala.

• Con 10 ingenieros, una IDP casi seguro es prematura. El problema del catálogo se resuelve con una página compartida; la fricción real es inconsistencia de tooling y golden paths ausentes, no falta de portal. Arregla los golden paths antes de pensar en un portal.
• Con 50 ingenieros aparece el umbral donde el portal aporta valor real: suficientes servicios, equipos y complejidad de toolchain para que el descubrimiento de servicios y el self-service cuesten de verdad. La pregunta pasa a ser cuál es el portal mínimo que reduce más fricción para más desarrolladores, y la respuesta casi siempre es un producto comercial configurado a tu toolchain. Compra la capa de catálogo y self-service; construye los golden paths y la automatización de despliegue.
• Con 200 ingenieros, el cálculo incluye más variables: catálogo genuinamente complejo, requerimientos de self-service más específicos, tooling propietario. El caso para una construcción a medida (o un Backstage muy extendido) se fortalece, y la capacidad dedicada de ingeniería de portal se vuelve más viable, con mejor retorno porque sirve a una población de desarrolladores más grande.

El patrón: producto comercial de 50 a 150 ingenieros, y recién entonces evaluar Backstage o una construcción a medida según las integraciones acumuladas y la capacidad de ingeniería disponible.

El espectro de vendor lock-in: lo real frente a lo teórico

El lock-in es el argumento más común para construir, y merece un tratamiento honesto. Los riesgos reales con un producto comercial son: que el proveedor suba precios con fuerza, que sea adquirido o discontinuado, que su roadmap se aleje de tus requerimientos, o que llegue a un límite de capacidad que no se pueda extender. Cada uno es posible; ninguno es particularmente común en productos establecidos con una base de clientes significativa.

El análisis debe ser concreto, no abstracto. Si este proveedor desapareciera mañana, ¿cuánto costaría migrar? En la mayoría de los productos comerciales, los datos del catálogo son exportables y las configuraciones están documentadas, así que la migración es un proyecto de meses, no una reconstrucción de años. Compáralo con el lock-in de una construcción a medida: cuando los ingenieros que la construyeron se van, su conocimiento se va con ellos. El lock-in del portal a medida es pérdida de conocimiento organizacional, y suele ser más caro que cambiar de proveedor.

Backstage, al ser open source graduado por la CNCF, elimina el riesgo de continuidad del proveedor a cambio de subir el requerimiento de mantenimiento de ingeniería. El trade es real: es la opción correcta cuando existe la capacidad para mantenerlo y los requerimientos de personalización lo justifican, no una alternativa universalmente más segura.

La vía híbrida: comprar una base y extender con disciplina

La decisión no es binaria entre "construir todo" y "comprar todo". Adoptar una base establecida (Port o Backstage) y extenderla para tus requerimientos específicos es a menudo la respuesta correcta y consistentemente subutilizada.

El caso de uso es claro: organizaciones donde el 80% de los requerimientos del portal son estándar (catálogo, integraciones comunes, self-service de flujos típicos) y el 20% es específico a sus patrones de ingeniería. Lo estándar se resuelve por configuración; lo específico, por plugins de Backstage, integraciones de Port o extensiones livianas sobre la API del producto. La capacidad que habría ido a construir lo estándar se redirige a lo que de verdad requiere trabajo a medida.

La vía híbrida exige disciplina. Su modo de falla más común es el scope creep: el equipo arranca con una base comercial y agrega integraciones a medida hasta que la capa custom cuesta más mantener que la base original. Mantén una frontera clara entre lo estándar (lo resuelve el producto) y lo específico (lo resuelve la extensión), y claridad arquitectónica sobre dónde vive el dato. Cuando una base y sus extensiones hacen supuestos contradictorios sobre la propiedad de un servicio, el resultado es un portal con datos inconsistentes que los desarrolladores no confían.

Golden paths y paved roads

Una IDP entrega su valor a través de golden paths: rutas opinadas y documentadas que el equipo de plataforma recomienda como camino por defecto. El término lo popularizó el equipo de plataforma de Spotify mientras construía Backstage. El concepto es anterior al nombre: en Netflix se llamaban paved roads; en Google, "boring solutions". La palabra clave en cualquier definición es voluntario. Un golden path se adopta porque es más rápido que la alternativa, no porque se imponga. Cuando hace falta forzarlo, el path falló como diseño, y el equipo de plataforma debe arreglar el path en lugar de exigir cumplimiento.

Cinco preguntas antes de decidir

Estas cinco preguntas, respondidas con honestidad, producen la decisión de construir o comprar con más fiabilidad que cualquier comparación de features.

1. ¿Qué fricción específica del desarrollador debe reducir este portal, y cómo vas a medir si la redujo? Sin un punto de fricción nombrado, un estado actual medible y una meta medible, la evaluación es prematura. Define el requerimiento primero.
2. ¿Cuál es la capacidad real de ingeniería para construir y mantener el portal, modelada como FTE a tres años? No la teórica: la que queda después del trabajo de fundación, la respuesta a incidentes y el soporte de features. Si la respuesta honesta es "0,5 FTE permanente", eso elimina la construcción a medida.
3. ¿Qué integraciones son específicas a tu toolchain, y los productos comerciales las cubren? Convierte la pregunta abstracta de "flexibilidad" en una lista concreta de requerimientos contrastada contra la documentación de cada producto.
4. ¿Cómo se ve un portal exitoso 12 meses después del lanzamiento, y quién es responsable de ese resultado? "El portal está en vivo" no es éxito. "El tiempo de onboarding bajó de 21 a 8 días" sí lo es. Define la métrica de resultado antes de decidir y asígnala a una persona.
5. ¿Cuál es la condición de salida si esta elección resulta equivocada? Define el camino de migración antes de empezar. Eso fuerza una evaluación concreta de los costos reales y evita la falacia del costo hundido que mantiene a las organizaciones en malas decisiones de herramienta más tiempo del razonable.

Cómo lo aborda Clouditive

El Foundations Framework secuencia el trabajo para que las decisiones de IDP no se tomen al revés. La fase Horizon establece la línea base (incluida una de experiencia del desarrollador que captura tiempo de incorporación, carga cognitiva y cumplimiento de paved roads), que es la base contra la cual se medirá la IDP. Blueprint diseña la arquitectura con la voz de los equipos de aplicación adentro desde el inicio. Forge construye por capas: infraestructura como código primero, después el golden path de CI/CD, y el portal al final, cuando ya hay algo significativo que exponer.

El patrón que vemos es consistente: las organizaciones que intentan construir una IDP sobre una capa de infraestructura sin medir y poco firme fallan durante la adopción. Arreglar la fundación primero no es un desvío; es la ruta directa.

¿Estás evaluando construir, comprar o extender una plataforma interna de desarrollo? Conversa con Clouditive y empieza por diagnosticar la capa de plataforma antes de elegir la herramienta.