Compra lo que ya es commodity y construye donde el workflow, la integración, la experiencia o el control crean una diferencia real. La decisión rara vez es binaria: usar productos y modelos gestionados y desarrollar sólo la capa diferencial suele ser la arquitectura más sensata.
El error clásico es comparar una licencia con horas de desarrollo. La comparación real incluye cobertura del workflow, gaps, trabajo manual residual, integración, operación, velocidad de cambio y coste de salir de la decisión dentro de dos años.
Dibuja entrada, pasos, sistemas, excepciones y resultado. Después pregunta cuánto cubre el producto sin workarounds. Una demo puede resolver el 80 % visible y fallar justo en el 20 % caro: permisos, casos límite, integraciones y operación.
Si no existe un proceso concreto, “build o buy” se convierte en una comparación abstracta de features.
| Señal | Comprar | Híbrido | Construir |
|---|---|---|---|
| Proceso | Estándar y estable | Estándar con capa diferencial | Propio y estratégico |
| Integración | Conectores suficientes | Producto + APIs/capa propia | Lógica o sistemas no cubiertos |
| UX | La estándar sirve | Se personaliza una parte | La experiencia es parte del valor |
| Control | No aporta poseerlo | Control sólo en puntos críticos | Control profundo es requisito |
| Time-to-value | Prioridad máxima | Equilibrio | Aceptas más construcción |
Si la tarea es común, el producto encaja con identidad y seguridad, dispone de integración suficiente y la experiencia estándar no rompe el proceso, comprar evita mantener infraestructura indiferenciada.
El valor del SaaS no es sólo llegar antes: es transferir actualizaciones, soporte, seguridad de plataforma y evolución de una capacidad que no te diferencia.
Desarrollo propio tiene sentido cuando el valor depende de lógica específica, varias herramientas deben coordinarse, la interfaz forma parte del workflow o los permisos y estados no caben bien en configuración estándar.
Si cada excepción obliga a exportar, copiar, corregir y reimportar, el “buy” puede haber trasladado el coste a operaciones.
Una arquitectura típica puede usar CRM, proveedor de modelos, sistema documental y una capa propia que concentra lógica, permisos, evaluación y UX. No necesitas entrenar un modelo ni reconstruir un CRM para tener una solución a medida.
La frontera correcta deja fuera del código propio lo que es commodity y conserva ownership donde aporta control o ventaja.
| Buy | Build |
|---|---|
| Licencias, consumo, usuarios, add-ons, conectores, consultoría, límites de volumen, trabajo manual residual. | Desarrollo, infraestructura, observabilidad, soporte, evolución, seguridad y conocimiento interno. |
Proyecta al volumen esperado y a un escenario de crecimiento. Una licencia barata por usuario puede escalar mal; un desarrollo caro puede amortizarse o convertirse en deuda si nadie mantiene el conocimiento.
Por cada requisito no cubierto pregunta: ¿qué persona hará el paso manual?, ¿cuántos minutos?, ¿cuántas veces?, ¿qué riesgo añade?, ¿qué workaround habrá que mantener? Ese coste recurrente convierte “el producto cubre casi todo” en una cifra comparable.
Los gaps pequeños pero frecuentes son capaces de destruir el caso económico.
Depender de un buen producto puede ser una decisión racional. El problema es la dependencia accidental: lógica crítica repartida en mecanismos propietarios, datos difíciles de exportar o automatizaciones sin contrato estable.
Protege las fronteras importantes: conserva tus datos, encapsula integraciones críticas, documenta esquemas y evita que una feature concreta defina toda la arquitectura sin necesidad.
Puedes comprar para validar rápido y construir después una capa diferencial. También puedes retirar software propio cuando el mercado resuelve mejor una capacidad que ya no aporta ventaja.
McKinsey señalaba en 2026 que el coste de construir está cambiando con herramientas de desarrollo asistido por IA; eso hace todavía más importante revisar la decisión con TCO y no con dogmas.
Respuestas directas para convertir la pregunta en una decisión de proyecto.
Cuando el caso es estándar, el producto cubre suficientemente el workflow y sus límites de integración, seguridad y coste son aceptables.
Cuando el valor depende de lógica propia, integración profunda, UX diferencial o control que un producto estándar no cubre sin workarounds caros.
No. La arquitectura híbrida es habitual: productos y APIs para lo commodity, código propio para la capa diferencial.
Con TCO: licencias, consumo y trabajo manual residual frente a desarrollo, infraestructura, soporte y evolución, proyectado al volumen esperado.
Una dependencia difícil de cambiar que no compra una ventaja equivalente. La dependencia puede ser racional si su valor supera el coste de salida.
Sí. Comprar para validar y construir después —o sustituir desarrollo propio por producto— son movimientos normales cuando cambian requisitos y mercado.
Comparamos el workflow completo, los gaps, el TCO y el coste de salida antes de decidir qué merece software propio.