Construir o comprar: cuándo la solución estándar sale más cara
Lo estándar es más barato hasta que cuentas configuración, integración y los procesos que doblas para que encaje. Un test para decidir de qué lado cae.
La respuesta por defecto es comprar, y para la mayoría de las capacidades el valor por defecto es correcto. No deberías construir autenticación, nómina, envío de correo ni un libro mayor contable. Son problemas resueltos donde la versión de otro es mejor que la que harás tú.
El valor por defecto se vuelve incorrecto en una situación concreta y predecible: cuando la capacidad es aquello que diferencia a tu negocio de sus competidores.
El test
Una pregunta separa la mayoría de los casos:
Si esto funcionara exactamente como funciona en tu competidor más cercano, ¿perderías algo?
Si la respuesta es no, compra. Gestión de gastos, onboarding de personal, tickets y almacenamiento documental pasan este test con holgura.
Si la respuesta es sí, estás mirando aquello por lo que los clientes realmente te pagan, y un producto hecho para el promedio de tu industria te hará promedio en eso.
| Tipo de capacidad | Por defecto | Excepción |
|---|---|---|
| Back office genérico | Comprar | Casi nunca construir |
| Flujo estándar de la industria | Comprar y configurar | Construir solo si configurar cuesta más que construir |
| Integración entre sistemas comprados | Construir delgado | Comprar un iPaaS está bien; comprar una caja negra no |
| Aquello en lo que compites | Construir | Comprar solo para validar demanda, con salida planificada |
| Registro regulado de verdad | Depende | Compra el motor, construye el flujo alrededor |
Los costos que hacen "comprar" más caro de lo que parece
El costo de licencia es el número de la comparación. Rara vez es el número más grande del total.
Configurar es desarrollar sin ingenieros. Una plataforma configurada en 200 pantallas por consultores es una base de código. No tiene control de versiones en el que confíes, ni suite de pruebas, ni revisión de código, y quienes la entienden facturan por hora. Suele ser más difícil de cambiar que el código a medida equivalente.
La integración es tuya de todos modos. Comprar no elimina el trabajo de integración; lo reubica. Y ahora integras contra el modelo de otro, en su calendario de releases, con sus límites de tasa.
El cambio de proceso es un costo real sin factura. Adoptar un producto significa adoptar el proceso que codifica. Cuando ese proceso es mejor que el tuyo, es un beneficio. Cuando es solo distinto, lo pagas en capacitación, excepciones y hojas de cálculo paralelas que crecen alrededor de lo que no encaja.
El costo de salida crece en silencio. Cada año de datos acumulándose en un modelo propietario sube el costo de irse. Pregunta qué contiene una exportación antes de firmar, no cuando quieras salir.
El híbrido que suele ganar
La mayoría de las buenas respuestas no es construir ni comprar. Es comprar el motor y construir el borde.
Otro opera el núcleo difícil y no diferenciador: el procesador de pagos, el proveedor de identidad, el data warehouse, la API del modelo. Tú construyes el flujo, las reglas de dominio y la interfaz que lo hacen específicamente tuyo.
Esto mantiene la construcción pequeña y la diferenciación en tus manos. Tiene un requisito: el componente comprado debe exponer una API real. Si no lo hace, compraste un sistema sobre el que no puedes construir, y cada extensión se convierte en automatización de pantalla o en un ticket de soporte.
La reversibilidad decide los casos ajustados
Cuando el análisis queda genuinamente empatado, elige la opción más barata de deshacer.
Comprar suele ser más barato de revertir temprano y mucho más caro de revertir tarde, conforme se acumulan datos y procesos. Construir es caro al inicio y se mantiene más o menos tan reversible como empezó, siempre que hayas mantenido limpias las fronteras.
Esa asimetría favorece comprar para validar una necesidad de la que no estás seguro, con un punto de decisión explícito al año, y construir cuando la necesidad esté probada y los requisitos hayan dejado de moverse.
Acertar la estimación del lado de construir
Si acabas en construir, el número depende de mucho más que la lista de funcionalidades. Los factores que de verdad lo mueven están en cómo dimensionar el costo de software a medida, y si reemplazas un sistema que debe seguir funcionando, la secuencia es una migración por partes.
Hacemos este análisis al inicio de la mayoría de los proyectos de ingeniería, y hemos recomendado comprar suficientes veces como para que sea un desenlace normal y no una cortesía. Cómo trabajamos y qué protegemos está en nuestras prácticas de seguridad.