Custom Software · Análisis a fondo
A medida o plataforma: la matriz de decisión build-vs-buy
Cuándo desarrollar software a medida y cuándo comprar una plataforma: una matriz de decisión basada en el ajuste al proceso, el coste total de propiedad, el lock-in, la propiedad del dato y el time-to-value.
ARQUITECTURA · BUILD-VS-BUY
Entra · Capacidades a habilitar
Sale · Build / Buy / Componer
Core frente a commodity (mapa de valor)
Descompone el sistema en sus capacidades y sitúa cada una en el eje core/commodity: separa lo que te diferencia en el mercado — y merece código propio — de lo que se ha vuelto commodity y simplemente se compra al proveedor más barato.
Encaje con el proceso
Mide cuán propietario es tu flujo: un proceso genérico con estándares de industria asentados empuja hacia la plataforma, mientras que un flujo que es parte de tu ventaja empuja hacia el a medida, porque aquí las soluciones alternativas que impone una plataforma cuestan más que el código a medida.
TCO a 5 años
Calcula el coste a cinco años incluyendo mantenimiento, integración y formación — no solo la licencia o el presupuesto inicial — porque la mayor parte del coste del software llega tras la puesta en producción, y eso es lo que da la vuelta al veredicto.
Lock-in y derechos de salida
Sopesa el coste de salida antes de entrar: contratos, portabilidad del dato e integraciones cableadas a fuego determinan si tendrás poder de negociación en la renovación o te quedarás sin él, frente a un proveedor que lo sabe.
Propiedad de los datos
Comprueba que el dato que te distingue siga siendo tuyo, exportable en estándares abiertos e independiente del proveedor: un solo elemento no exportable puede dar la vuelta a la decisión, porque un activo convertido en rehén pesa más que cualquier ahorro de precio de catálogo.
Time-to-value
Equilibra la urgencia del valor con la durabilidad de la ventaja: una solución probada ya disponible te pone en marcha ahora, mientras que un diferenciador estructural justifica una implementación más larga y sostenida.
Las señales de que tu línea build-vs-buy se trazó en el lugar equivocado
La pregunta nunca es «a medida o plataforma». Es: qué capacidad merece código propio y cuál es una commodity que se compra. Estos síntomas indican que la línea se trazó en el sitio equivocado.
- Estás personalizando una plataforma estándar hasta que ya no se parece a sí misma: cada versión del proveedor rompe tu configuración, y el «listo para usar» se ha convertido en un proyecto de desarrollo permanente.
- Has construido una commodity desde cero — autenticación, pagos, notificaciones — gastando capacidad de ingeniería en problemas que el mercado ya resolvió, en lugar de en tu ventaja competitiva.
- El dato que te distingue vive dentro de un proveedor en un formato propietario y sin exportación a estándares abiertos: ya no es un activo, es un rehén.
- Nadie calculó nunca la cifra a cinco años : la decisión se tomó sobre un precio de licencia o un presupuesto de desarrollo, ignorando el mantenimiento, la integración y la formación que dominan el ciclo de vida.
- Cambiar de proveedor es impensable : contratos plurianuales, datos no portables e integraciones cableadas a fuego han elevado el coste de salida a un nivel que te quita todo poder de negociación en la renovación.
Para CTO, COO y direcciones de operaciones que deben decidir dónde invertir capacidad de ingeniería y dónde apoyarse en el mercado, con criterios que se sostengan ante el consejo.
Compra la commodity, construye lo que te distingue
La regla operativa más sólida no es financiera, es estratégica: situar cada capacidad en el mapa del valor y decidir según dónde está, no según las preferencias de quien escribe el código. Una disciplina formalizada por el Wardley Mapping.
Core vs commodity, no gustos personales
Una capacidad que te diferencia en el mercado y evoluciona rápido merece código propio. Una capacidad que se ha vuelto commodity — la misma para ti y para tus competidores — es un centro de coste: se compra al proveedor más barato y se sigue adelante. Construir una commodity es quemar capacidad de ingeniería en un problema ya resuelto.
El ajuste al proceso es la verdadera divisoria
Si tu flujo es genérico y la industria tiene estándares asentados, una plataforma gana por velocidad. Si el flujo es propietario y parte de tu ventaja, la plataforma obliga a soluciones alternativas que, sumadas, cuestan más que el código a medida. Una plataforma te dobla a su modelo; el a medida dobla el software al tuyo.
Configurar no es gratis
Entre comprar y construir hay una tercera vía — configurar e integrar — pero no es neutra. Encajar una plataforma compleja en un flujo específico, con migración de datos y formación, conlleva un coste real antes incluso de la primera transacción. La trampa es la sobrepersonalización: parte de la configuración recomendada e itera sobre los datos de uso, no lo reescribas todo el primer día.
Compose: lo mejor de ambos, con disciplina
El enfoque maduro es híbrido: capacidades del mercado para las funciones estándar, conectadas mediante API documentadas, y la capacidad de ingeniería interna concentrada en lo que de verdad te distingue. Es la lógica composable (microservicios, API-first, cloud-native, headless): componentes reemplazables que cambian sin derrumbar todo lo conectado a ellos.
La decisión debe ser estructural, no emocional
Mapear las capacidades hace la elección legible: ves dónde se sitúa cada componente en el eje génesis-commodity, de qué depende y hacia dónde empuja la evolución. La línea build-vs-buy deja de ser una preferencia de departamento y se convierte en una decisión de arquitectura defendible.
Cómo trazamos la línea, capacidad por capacidad
No decidimos «a medida o plataforma» para todo el sistema. Descomponemos el sistema en capacidades y hacemos pasar cada una por los mismos gates. El resultado es un mapa, no una opinión.
Descomponemos el sistema en sus capacidades y situamos cada una en el eje core/commodity: qué te diferencia, qué se ha vuelto estándar. Esto separa lo que vale código propio de lo que simplemente compras.
Para cada capacidad comprobamos cuán propietario es tu flujo. 60-70 % estándar con excepciones manejables: configurar. Flujo que es parte de la ventaja: construir. Flujo genérico: comprar.
Calculamos el coste a cinco años incluyendo mantenimiento, integración y formación — no solo la licencia o el presupuesto inicial. En paralelo medimos el coste de salida: portabilidad del dato, derechos de exportación, dependencia de las integraciones.
Cada capacidad recibe un veredicto — build, buy o compose — y su lugar en la arquitectura. Las commodities van tras API documentadas; el diferenciador se vuelve código propio, con el dato bajo tu control.
Del mapa de capacidades a una matriz de decisión defendible en semanas, no en un trimestre de estudios.
Build, Buy o Compose: los gates de decisión
Cada capacidad pasa por cinco palancas. No es una suma de puntos: una sola palanca puede dar la vuelta a la decisión (un dato propietario no exportable pesa más que cualquier ahorro de precio de catálogo).
| Palanca de decisión | Empuja hacia BUY / plataforma | Empuja hacia BUILD / a medida |
|---|---|---|
| Posición en el mapa | Capacidad commodity, idéntica a los competidores | Capacidad core que te diferencia y evoluciona rápido |
| Ajuste al proceso | Flujo genérico, estándares de industria asentados | Flujo propietario; la plataforma obliga a soluciones alternativas costosas |
| TCO a 5 años | Mantenimiento y riesgo a cargo del proveedor | Volumen y duración de uso amortizan el coste de desarrollo |
| Lock-in y salida | Exportación a estándares abiertos, salida por conveniencia, integraciones por API | El dato crítico debe seguir siendo propio, independiente del proveedor |
| Time-to-value | Se necesita valor ya; solución probada ya disponible | La ventaja justifica una implementación más larga y sostenida |
Los cuatro activos que la matriz pone a salvo
Una decisión build-vs-buy bien hecha no solo optimiza el coste. Protege lo que, una vez perdido, no se vuelve a comprar.
Propiedad del dato
El dato que te distingue sigue siendo tuyo, exportable en formatos estándar e independiente del proveedor. No un rehén en un silo propietario, sino un activo negociable que te da poder en la renovación.
Capacidad de ingeniería bien gastada
Cada hora de desarrollo va a tu ventaja competitiva, no a una commodity que el mercado ya resolvió. A medida donde cuenta, mercado donde no cuenta.
Derechos de salida
Portabilidad del dato, integraciones por API documentadas y ningún cableado propietario mantienen bajo el coste de cambio. La posibilidad de irte es lo que te mantiene en condiciones justas.
Arquitectura composable
Capacidades reemplazables conectadas por API: un componente cambia sin que el resto se derrumbe. El sistema sigue vivo en el tiempo, no un monolito que rehacer.
Construye lo que te distingue, compra lo que compartes con tus competidores.
Las preguntas que nos hacen antes de decidir
¿El a medida es siempre más caro que una plataforma?
No en el ciclo de vida. La mayor parte del coste del software llega tras la puesta en producción — mantenimiento, integración, formación. En una commodity la plataforma gana porque traslada ese coste al proveedor. En una capacidad core con alto volumen y larga duración de uso, el a medida se amortiza mientras el precio de una plataforma sube con el tiempo. La respuesta está en el TCO a cinco años, no en el precio de entrada.
¿Puedo comprar ahora y construir después?
Sí, y a menudo es el movimiento correcto — siempre que no te dejes atrapar. Comprar para arrancar rápido tiene sentido si el dato sigue siendo exportable en estándares abiertos y las integraciones pasan por API documentadas. Si el proveedor retiene tu dato en un formato propietario, «después» se convierte en una migración costosa que nunca harás. La portabilidad se negocia en la firma, no en el divorcio.
¿Cómo evitamos construir algo que el mercado hace mejor?
Mapeando cada capacidad antes de escribir código. Si una función se ha vuelto estándar — la misma para ti y para tus competidores —, construirla es capacidad de ingeniería quemada. El código propio se reserva para lo que te diferencia y evoluciona; todo lo demás se compra o se compone vía API. Esa disciplina separa una inversión de un gasto.
Casos
Del problema al resultado — anonimizados.
La plataforma desfigurada
Problema Un retailer había personalizado una plataforma de e-commerce estándar hasta que ya no se parecía a sí misma: cada versión del proveedor rompía la configuración y el «listo para usar» se había convertido en un proyecto de desarrollo permanente, con el motor de pricing — su verdadero diferenciador — atrapado en restricciones que no controlaban.
Método Mapeamos las capacidades en el eje core/commodity: catálogo, checkout y pagos mantenidos en la plataforma como commodities tras API documentadas; el motor de pricing y promociones, parte de la ventaja competitiva, extraído como servicio propio cableado de forma composable.
Resultado Las versiones del proveedor dejaron de romper el sistema, la capacidad de ingeniería volvió al pricing en vez de a las soluciones alternativas, y la lógica que los distingue se convirtió en código suyo — reemplazable sin derrumbar el resto.
El dato tomado como rehén
Problema Una firma de servicios financieros mantenía el dato de cliente que la distinguía dentro de un proveedor, en formato propietario y sin exportación a estándares abiertos: cambiar era impensable y en la renovación el proveedor tenía todo el poder de negociación, porque la salida estaba de hecho cerrada.
Método Aplicamos los gates de lock-in y propiedad del dato: renegociamos derechos de exportación a formatos estándar en el vencimiento del contrato, movimos las integraciones críticas a API documentadas y devolvimos el dato diferenciador al control interno, dejando las funciones commodity donde estaban.
Resultado El coste de salida cayó hasta el punto de restaurar el poder de negociación en la renovación, el dato volvió a ser un activo negociable en vez de un rehén, y la posibilidad de irse es lo que los mantuvo en condiciones justas.
La commodity construida desde cero
Problema Un operador logístico había construido desde cero capacidades ya commodity — autenticación, notificaciones, gestión de usuarios — quemando capacidad de ingeniería en problemas que el mercado ya había resuelto, mientras la planificación de rutas, su verdadera ventaja, quedaba infrainvertida.
Método Hicimos pasar cada capacidad por el mapa del valor y el TCO a cinco años: retiramos el a medida en las commodities a favor de servicios de mercado tras API, y concentramos a los desarrolladores en la optimización de rutas, donde el volumen y la duración de uso amortizan el código a medida.
Resultado Cada hora de desarrollo volvió al diferenciador, el mantenimiento de las commodities pasó a los proveedores, y la arquitectura se volvió composable — componentes reemplazables que cambian sin rehacer todo el bloque.
Profundiza más
Arquitectura de producto de IA→
Dónde acaba la commodity y empieza el código propio cuando el sistema es IA-nativo.
RAG y grounding→
Compra el modelo, construye el grounding sobre el dato que te distingue.
Gobernanza de la adopción de IA→
Criterios defendibles ante el consejo para decidir build, buy o compose en IA.