Tarde o temprano, cualquier equipo que trabaja con datos llega a la misma encrucijada: adoptar una herramienta que ya existe en el mercado o desarrollar una solución a medida. La pregunta parece técnica, pero es sobre todo una decisión de negocio. Implica dinero, tiempo, riesgo y la forma en que la empresa quiere competir en los próximos años.
El error más común es responder por instinto. Hay quien compra siempre, por comodidad, y acaba rehén de una herramienta que nunca hace exactamente lo que hacía falta. Y hay quien construye siempre, por gusto por la ingeniería, y descubre demasiado tarde que se pasa los días manteniendo software que no es, en realidad, su negocio. Ninguno de los extremos es una estrategia.
Este artículo propone un método sencillo para decidir con criterios claros en lugar de preferencias personales. Veremos cuándo comprar compensa, cuándo construir compensa, y por qué la respuesta correcta es, muchas veces, una mezcla de las dos.
Qué está realmente en juego en esta decisión
La elección entre comprar y construir rara vez tiene que ver con la funcionalidad visible. Dos soluciones pueden mostrar el mismo gráfico en pantalla y tener implicaciones completamente distintas a tres años. Lo que está en juego es dónde quiere la empresa colocar su esfuerzo escaso: ingeniería, mantenimiento, formación y atención de gestión son recursos limitados.
Comprar cambia dinero por tiempo y por previsibilidad. Se paga una licencia y se recibe algo que ya funciona, probado por cientos de otros clientes. Construir cambia tiempo por control: se gana una solución que encaja en el proceso exacto de la empresa, pero se asume la responsabilidad de mantenerla viva mientras el negocio exista.
Antes de comparar proveedores o estimar líneas de código, conviene responder a una pregunta incómoda: ¿esta capacidad es una ventaja competitiva o solo algo que necesitamos tener? La respuesta orienta casi todo lo demás.
Cuándo compensa comprar
Comprar es casi siempre la decisión correcta cuando el problema es común y ya está bien resuelto por otros. Facturación, gestión de campañas, un CRM, una herramienta de cuadros de mando genéricos: nada de esto distingue a la empresa de sus competidores, y todos necesitan lo mismo. Reinventar lo que el mercado ya ofrece a un precio asequible es malgastar el recurso más caro que existe: el tiempo de personas capaces.
Hay señales claras de que comprar es el camino:
- El problema es estándar y varios proveedores maduros ya lo resuelven.
- La empresa no tiene —ni quiere tener— un equipo dedicado a mantener la solución.
- El tiempo hasta obtener valor cuenta: necesita resultados en semanas, no en trimestres.
- Los requisitos son estables y no cambian de forma imprevisible.
- El coste de la licencia es claramente inferior al coste de desarrollar y mantener algo equivalente.
Comprar tiene además una ventaja sutil: transfiere parte del riesgo al proveedor. Las actualizaciones de seguridad, la corrección de errores y la compatibilidad con nuevos sistemas pasan a ser problema de otra persona. Para muchas empresas, esa tranquilidad vale más que cualquier funcionalidad extra.
Cuándo compensa construir
Construir tiene sentido cuando la solución toca aquello que hace diferente a la empresa. Si el proceso es la propia ventaja competitiva —un modelo de precios particular, una forma de encaminar pedidos que nadie más tiene, una lógica de recomendación afinada durante años—, entregarlo a una herramienta genérica es renunciar precisamente a lo que distingue al negocio.
También se justifica cuando ninguna herramienta del mercado encaja sin contorsiones. A veces el coste de moldear la empresa a un producto rígido es superior al coste de construir algo propio. Y está el caso de la integración: cuando la solución necesita conversar de forma profunda con sistemas internos, una API bien diseñada a medida puede ahorrar meses de adaptaciones forzadas.
Construir exige, eso sí, una honestidad brutal sobre la capacidad. No basta con tener quien escriba el código inicial; hace falta quien lo mantenga durante años, documente decisiones y forme a quien llega después. El software sin dueño es una deuda que siempre vence en el peor momento.
El coste total que casi nadie suma
La comparación ingenua pone el precio de la licencia de un lado y el salario de un programador del otro. Es una cuenta engañosa. El coste real de construir incluye mucho más que el desarrollo inicial: mantenimiento, corrección de errores, actualizaciones de seguridad, alojamiento, monitorización, documentación y el tiempo de gestión para coordinarlo todo.
Una regla empírica útil es que el desarrollo inicial suele representar una fracción del coste a lo largo de la vida de un sistema; el resto llega después, año tras año. Una solución que costó tres meses construir puede consumir a una persona a tiempo parcial durante una década para mantenerla. Ese coste es real, aunque no aparezca en ninguna factura.
Del lado de comprar también hay costes ocultos: integración con el resto del ecosistema, formación de los equipos, posibles tarifas por usuario que crecen con la empresa y el riesgo de depender de un proveedor que un día sube el precio o es adquirido. Un cálculo honesto de coste total de propiedad suma todo esto, de ambos lados, a lo largo de tres a cinco años.
El tercer camino: comprar y extender
La oposición entre comprar y construir es, en la mayoría de los casos, falsa. Las soluciones más equilibradas compran la base y construyen solo la cima —la capa fina donde reside la ventaja real—. Se compra la plataforma de datos, el motor de cuadros de mando o el servicio de infraestructura, y se desarrolla encima la lógica específica que ningún proveedor trae de fábrica.
Este modelo evita los dos peores escenarios: pagar caro por algo genérico que no llega, o hundirse en reconstruir lo que ya existe barato. La pregunta deja de ser "¿comprar o construir?" y pasa a ser "¿dónde trazamos la línea entre lo que compramos y lo que construimos?". Regla práctica: compra lo que es común, construye lo que es tuyo.
Una buena arquitectura ayuda a mantener esa línea flexible. Aislar la parte comprada tras interfaces claras permite cambiar de proveedor más tarde sin reescribir la solución entera. Es lo contrario de casarse a ciegas con una herramienta y quedar atrapado cuando las condiciones cambian.
Preguntas que hacer antes de decidir
Antes de firmar un contrato o abrir un proyecto de desarrollo, conviene reunir a las personas adecuadas en torno a estas preguntas:
- ¿Esta capacidad es una ventaja competitiva o solo algo que tenemos que tener?
- ¿Existen proveedores maduros? ¿Cuántos, y desde hace cuánto están en el mercado?
- ¿Tenemos, de forma sostenible, quien mantenga esta solución dentro de tres años?
- ¿Cuál es el coste total de ambos lados a lo largo de cinco años, y no solo en el primero?
- ¿Qué probabilidad hay de cambios en los requisitos, y con qué rapidez los acompaña cada opción?
- Si compramos, ¿qué tan fácil es salir después? Si construimos, ¿qué tan fácil es que alguien nuevo asuma el relevo?
Si la mayoría de las respuestas apunta a "común, estable, con buenos proveedores y sin equipo para mantenerlo", compre. Si apunta a "distintivo, específico, cambiante y central para el negocio", construya. La vida real casi siempre queda en medio, y ahí es donde el modelo de comprar y extender brilla.
Minicaso: una empresa de distribución decidiendo
Una empresa de distribución de material eléctrico, con cerca de 200 empleados, quería mejorar la forma en que preveía la demanda y gestionaba el stock. El equipo de sistemas propuso construirlo todo desde cero: un motor de previsión a medida, integrado con el almacén. La estimación inicial era de cuatro meses de trabajo.
Al sumar el coste total, el panorama cambió. Los cuatro meses de desarrollo eran solo el comienzo; mantener el sistema exigiría, de forma realista, media persona a tiempo completo al año, algo que el equipo de tres no podía ceder. Al mismo tiempo, existían herramientas maduras de previsión de demanda a un coste anual equivalente a unas pocas semanas de ese trabajo interno.
La decisión final fue híbrida. Compraron una plataforma de previsión para el trabajo pesado y construyeron solo una capa fina de integración con su sistema de almacén —la parte que sí era específica del negocio—. En ocho semanas estaban en producción. Un año después, la rotura de stock en sus artículos principales había caído cerca de un 30% y el equipo aún podía mantener lo poco que era realmente suyo. Lo que los salvó no fue elegir comprar o construir, sino sumar con honestidad el coste de cada camino.
En la práctica
Build vs buy no es una cuestión de gusto ni de orgullo de ingeniería. Es una decisión de asignación de recursos que se toma mejor con números que con instinto. Compre lo que es común y no lo distingue; construya lo que es suyo y lo hace diferente; y, en la duda, compre la base y construya solo la cima.
Antes de decidir, sume el coste total de ambos lados a lo largo de varios años, sea honesto sobre su capacidad de mantener lo que construye, y diseñe la solución para poder cambiar de idea más tarde. La peor decisión no es comprar ni construir: es elegir por costumbre, sin haber hecho las cuentas.
