Cada trimestre, algún equipo dentro de su organización está reconstruyendo algo que ya existe como SaaS maduro. Y cada trimestre, algún otro equipo está atrapado en un contrato de SaaS que cuesta más que tres ingenieros y entrega menos que uno. La decisión build vs buy no es una preferencia arquitectónica: es una decisión de capital con consecuencias a cinco años. En 2026, con LLMs reduciendo el coste marginal de escribir código pero no el coste de operarlo, el cálculo ha cambiado, pero el marco de decisión sigue siendo el mismo.
Este artículo presenta un marco operativo que hemos aplicado en docenas de evaluaciones para clientes de mid-market y enterprise. No es una matriz académica: es una secuencia de preguntas en orden estricto.
La regla del diferenciador competitivo
La primera pregunta no es técnica. Es estratégica: ¿este sistema es parte de su diferenciador competitivo, o es infraestructura? Si su negocio compite en velocidad de underwriting, su motor de scoring es diferenciador. Su sistema de gestión documental, no. Si compite en personalización de catálogo, su motor de recomendaciones es diferenciador. Su CRM, no.
La regla operativa: nunca reconstruya commodity. Si el dominio del problema está resuelto por veinte vendors maduros con economías de escala que usted nunca alcanzará (autenticación, facturación, mesa de ayuda, observabilidad básica, correo transaccional), comprar siempre gana en horizonte de cinco años. Construir aquí es egotismo de ingeniería disfrazado de control.
El anti-patrón clásico que vemos repetido: equipos que invierten dieciocho meses construyendo su propio sistema de feature flags porque “queríamos control total”. A los dos años el equipo original se fue, nadie quiere mantener el código y migran a LaunchDarkly de todos modos, esta vez con deuda técnica y un sistema legacy paralelo. El coste real fue tres veces el precio de licencia que querían evitar.
Modelo TCO realista, no de presentación
Casi todos los TCO comparativos están sesgados a favor de “build” porque omiten el coste verdadero de operar software propio. Un modelo honesto incluye al menos siete líneas para la opción de construir.
- Desarrollo inicial: ingenieros senior × meses × carga (1.4 – 1.6 × salario), ajustado por retraso típico del 40%.
- Mantenimiento perpetuo: 20-30% del coste inicial anualmente, indefinidamente. Esta línea suele faltar.
- Infraestructura y operación: compute, storage, redes, observabilidad, backups, DR.
- Cumplimiento y seguridad: auditorías SOC 2 o ISO 27001 propias, pentests, gestión de vulnerabilidades.
- Coste de oportunidad: qué dejó de construir su equipo de plataforma mientras mantenía esto.
- Coste de churn de ingenieros: sistemas legacy aburridos aumentan la fricción de retención.
- Coste de salida: qué pasa cuando este sistema necesita ser reemplazado en 2031.
Para la opción de comprar, el TCO incluye licencia, integración inicial, mantenimiento de integraciones cuando el vendor cambia su API, costes de switching (volveremos a esto), y la prima de riesgo de que el vendor sea adquirido o suba precios 3× en una renovación. En nuestra experiencia, un TCO honesto a cinco años convierte muchas decisiones “obvias” en su opuesto.
Análisis de switching cost
El switching cost es lo que separa una decisión reversible de una que define la siguiente década. Antes de firmar un SaaS, calcule cuánto cuesta salir. Si la respuesta es “no podemos salir”, está comprando dependencia, no software.
Indicadores de switching cost alto
- El proveedor controla un formato de datos propietario sin export estandarizado.
- La lógica de negocio crítica vive en configuraciones imposibles de versionar fuera de la plataforma.
- Integraciones profundas con identity, eventos y data warehouse que tomaron meses construir.
- El equipo construyó conocimiento operativo específico de la herramienta que no transfiere.
- Los usuarios finales tienen flujos de trabajo cementados que requieren rediseño organizacional para cambiar.
Cuando el switching cost es alto, la decisión “comprar” se acerca peligrosamente a “construir un sistema legacy que no controlamos”. En estos casos, el patrón híbrido suele ganar: comprar el motor, construir las capas de abstracción que lo hagan reemplazable.
El patrón híbrido: comprar el motor, construir el envoltorio
La falsa dicotomía build/buy ignora la tercera opción que normalmente gana en sistemas críticos: comprar capacidades commodity y construir una fachada propia que las componga. Stripe es su motor de pagos, pero el flujo de checkout, la lógica de retry, los reportes financieros internos son suyos. Twilio mueve los SMS, pero la orquestación de campañas multicanal vive en su código.
Este patrón maximiza dos cosas: velocidad inicial (el motor ya funciona) y opcionalidad futura (su fachada puede señalar a otro motor si Stripe se vuelve hostil o un competidor lanza algo 10× mejor). Es más caro que SaaS puro en el corto plazo y más barato que “build” puro siempre. Es la respuesta correcta para sistemas que tocan diferenciador competitivo pero descansan sobre commodity bien resuelto.
Cuándo aplica el híbrido
- Sistemas de pago, mensajería, búsqueda, autenticación cuando su negocio depende de UX diferenciada.
- Plataformas de datos donde el storage es commodity (Snowflake, BigQuery) pero los modelos semánticos son suyos.
- Capas de IA donde los foundation models son commodity (OpenAI, Anthropic, Bedrock) pero los prompts, evals y orquestación son su producto.
- Observabilidad donde el backend es commodity (Datadog, Grafana Cloud) pero los SLOs y runbooks son específicos.
El error de los LLMs en 2026
Una distorsión nueva: muchos equipos asumen que GitHub Copilot y Claude reducen el coste de “build” tanto que ahora es trivial reconstruir todo. Es un error. Los asistentes de IA reducen el tiempo de escribir código en un 20-40%. No reducen el tiempo de diseñar sistemas correctos, operar producción 24/7, migrar esquemas en vivo, o cumplir con SOC 2.
El coste total de propiedad de software propio sigue dominado por operación y mantenimiento, no por escritura inicial. La IA hace que construir un MVP sea más rápido. No hace que mantener un sistema en producción durante diez años sea más barato. Las decisiones build/buy que se justifican hoy con “ahora con IA es trivial” envejecerán mal.
Marco de decisión en cinco preguntas
El proceso operativo que recomendamos antes de cualquier decisión build vs buy material (digamos, mayor a 250k USD a tres años):
- 1. ¿Es diferenciador competitivo? Si no, comprar por defecto. La única excepción razonable es regulación que prohíbe SaaS.
- 2. ¿Existe SaaS maduro? Tres o más vendors viables con clientes de referencia comparables. Si la categoría es nueva, espere doce meses o construya un MVP delgado mientras tanto.
- 3. ¿Cuál es el TCO honesto a cinco años? Incluyendo operación, mantenimiento, churn de ingenieros y coste de salida. No solo licencia.
- 4. ¿Cuál es el switching cost de la opción comprar? Si es prohibitivo, evalúe híbrido o negocie cláusulas de portabilidad de datos contractualmente.
- 5. ¿Quién es dueño del sistema en cinco años? Si la respuesta es “nadie sabe”, está construyendo deuda técnica con presupuesto de capex.
El error de gobernanza: nadie dueño del portfolio
Incluso cuando cada decisión individual es razonable, el portfolio agregado de decisiones build/buy puede ser un desastre si nadie es dueño de la vista organizacional. Es común ver organizaciones donde tres equipos compraron tres herramientas distintas para hacer lo mismo (gestión de tareas, observabilidad, feature flags) porque cada equipo decidió aisladamente y nadie consolidó. El coste agregado es múltiplos del coste óptimo.
El antídoto es un rol o comité de arquitectura que mantiene visibilidad de qué se ha comprado, qué se ha construido y qué se está evaluando. No para vetar decisiones, sino para forzar que la conversación incluya “ya tenemos algo parecido en producción” antes de duplicar. Las organizaciones maduras tienen un catálogo de capabilities con dueños asignados, y cada nueva decisión build/buy debe consultar el catálogo.
Este patrón se vuelve crítico cuando la organización pasa de 200 a 1000 empleados. Antes, la coordinación informal funciona; después, el portfolio explota silenciosamente y la factura SaaS agregada se vuelve inexplicable.
Negociación contractual: la parte que los técnicos ignoran
La decisión de comprar no termina cuando se elige el vendor. Termina cuando se firma el contrato, y los términos importan más que el precio inicial. Los puntos contractuales que protegen valor a cinco años:
- Cláusula de portabilidad de datos: derecho explícito a exportar todos los datos en formato estándar legible por máquina, con SLA de tiempo de respuesta, sin coste adicional ni en una sola ocasión.
- Límite de incremento anual: cap sobre el aumento de precio en renovaciones (típicamente 5-7%). Sin esto, vendors duplican precios cuando el switching cost es alto.
- SLA financieramente respaldado: los SLAs que no incluyen créditos materiales son marketing.
- Derechos de auditoría: capacidad de auditar seguridad y cumplimiento del vendor en eventos materiales, no solo en informes SOC 2 anuales.
- Cláusula de cambio de control: qué pasa si el vendor es adquirido por un competidor o por private equity con historial de subir precios agresivamente.
Estos términos rara vez se otorgan sin pedirlos. Y una vez que se firma el contrato sin ellos, son imposibles de añadir hasta la renovación. La organización con disciplina contractual paga menos a cinco años aunque pague un poco más al inicio.
Cuándo aplica este marco, cuándo no
Cuándo aplica: decisiones de sistemas de negocio o plataforma con horizonte de tres a cinco años, organizaciones con presupuesto y disciplina para hacer TCO honesto, equipos donde “construir” significa equipos dedicados y no proyectos paralelos de ingenieros sobrecargados.
Cuándo no aplica: experimentos de producto sub-trimestrales (la velocidad domina, compre lo que funcione hoy y resuelva después), sistemas regulatoriamente forzados a residir on-premise (la decisión está tomada antes de comenzar), y empresas en estadio early donde “comprar” simplemente no es financiable y el equipo construye porque es lo único viable.
La pregunta correcta no es “build vs buy”. Es: ¿qué combinación de build, buy y orquestar maximiza el valor del próximo dólar invertido, dado nuestro horizonte, nuestro diferenciador y nuestra capacidad operativa real? Las organizaciones que responden esta pregunta con disciplina dejan de pelear esta batalla cada trimestre y la convierten en una capacidad institucional.
