Construir o comprar en 2026: qué cambió y qué no cambió en absoluto

Durante unos quince años la respuesta a "¿deberíamos construir esto?" fue casi siempre no, y era el consejo correcto.

Construir significaba un proyecto largo, un equipo que había que contratar, una obligación de mantenimiento para siempre y una probabilidad real de producir algo peor que el producto que podías licenciar el martes. Comprar significaba una suscripción y el problema de alguien más. Quien recomendara "construir" necesitaba una razón inusualmente buena.

Ese consejo hoy está equivocado para una categoría específica y creciente de software, y sigue siendo completamente correcto para otra. Distinguirlas es casi todo el valor de esta decisión, y no es donde está ocurriendo la mayor parte de la discusión.

Qué cambió de verdad

Se movieron cuatro cosas al mismo tiempo, por eso la conclusión se movió en lugar de solo tambalearse.

El costo de validar una construcción se desplomó. Esto importa más que el costo de construir. El riesgo histórico no era que construir fuera caro: era que te enterabas dieciocho meses después si la cosa estaba bien. Cuando existe una versión funcional en días, ese modo de falla caro prácticamente desaparece.

El precio por usuario empezó a romperse. Los modelos puros por asiento cayeron de alrededor de 21% a 15% del mercado en doce meses. No es una moda de precios; es lo que pasa cuando el trabajo lo hacen agentes y no personas ocupando asientos. Un modelo que cobraba por plantilla deja de describir el valor que entrega.

Integrar dejó de ser la partida más grande. Lo escribimos aparte en el costo de integrar está bajando, y es el insumo silencioso de todo caso de construcción, porque la razón por la que el software a la medida solía ser impagable rara vez era el software.

La presión regulatoria empezó a favorecer el control. En industrias reguladas, poder decir dónde se tomó una decisión, sobre qué datos y bajo la responsabilidad de quién ya es un requisito de compra y no un extra deseable. Eso es más fácil de garantizar dentro de tu propia frontera.

Que Klarna haya reemplazado su CRM licenciado por un sistema construido internamente es el ejemplo de portada, y la proyección de Gartner de que 35% de las herramientas SaaS de un solo propósito serán desplazadas por agentes antes de 2030 es la forma proyectada de esto.

Qué no cambió en absoluto

Aquí está la parte que se salta, y es la parte que decide si tu proyecto funciona.

Construir no es la mitad cara. Operar sí. La construcción nunca fue el costo principal, que es justamente por qué abaratarla cambia menos de lo que sugiere el entusiasmo. Alguien tiene que parcharlo, monitorearlo, arreglarlo a las 2 de la mañana y seguir entendiéndolo en tres años. Construcción barata más cero capacidad de operación produce un activo que calladamente se vuelve un pasivo, normalmente por el mes nueve.

Nadie reconstruye un sistema de registro por capricho. Tu contabilidad, tu sistema central de pólizas, tu control escolar. Son lentos, profundos, aburridos y enormemente caros de equivocar, y su valor está en ser poco emocionantes durante una década. La disrupción es real en los bordes y mucho menor en el centro.

Sigues sin poder construir tu salida de un problema de definiciones. Si dos áreas no coinciden en qué significa un campo, construir software producirá una respuesta segura, consistente y en disputa, pero más rápido. Lo decimos en casi todos los proyectos y aterriza como la mitad de las veces.

Las obligaciones de cumplimiento no preguntan quién lo escribió. Comprar software transfiere parte del riesgo a un proveedor. Construirlo lo conserva completo. Para algunas organizaciones ese es justo el punto; para otras es una obligación que no costearon.

La decisión, en la forma en que sí la usamos

No una matriz. Cuatro preguntas, en orden, y el primer "no" es tu respuesta.

1. ¿Es así como te diferencias de tus competidores? Si el proceso es genuinamente tuyo, lo que haces mejor que las firmas con las que compites, comprar significa adoptar la versión de alguien más y parecerte un poco más a ellos. Construye. Si es nómina, cómprala, y no la romantices.

2. ¿Hay un producto disponible que quede sin doblar tu operación? La prueba honesta no es la lista de funcionalidades. Es: ¿cuántos de tus casos reales requieren un rodeo? Un producto que cubre 85% y necesita una hoja de cálculo para el resto no reemplazó una hoja de cálculo: le agregó una suscripción.

3. ¿Puedes operarlo una vez que exista? No construirlo. Operarlo. ¿Hay un nombre asignado, presupuesto el próximo año y alguien que conteste cuando se descomponga? Si no, compra, o construye con un socio que se quede. Esta es la pregunta que hace fracasar más proyectos y la que menos se hace.

4. ¿Equivocarse aquí tiene consecuencias por las que tendrás que responder? Si un regulador, una aseguradora o un juez puede llegar a preguntar cómo se tomó una decisión, necesitas control del razonamiento y del registro. Eso empuja hacia construir, o hacia un proveedor que te dé ambos por contrato.

Dónde decimos "ninguna de las dos"

La recomendación que menos esperan los clientes de una firma que construye software es que no encarguen ninguno.

Pasa con la frecuencia suficiente como para ser uno de nuestros compromisos declarados, y las situaciones se repiten:

• El proceso está roto, no el software. Automatizar una cadena de aprobación con cuatro pasos innecesarios produce una versión rápida y cara de una cadena de aprobación innecesaria.
• El problema real es una integración. A veces una plataforma entera propuesta existe para mover datos entre dos sistemas que podrían simplemente conectarse.
• El sistema está bien y los datos son un desastre. Software nuevo encima de registros duplicados hereda los duplicados y agrega una migración.
• Nadie es dueño del resultado. Si ningún directivo responde por el resultado, el proyecto se entregará y no se adoptará. Preferimos decirlo.

Decir esto nos cuesta un proyecto y nos gana los siguientes tres, lo cual no es altruismo: es la única versión de este negocio que compone.

En resumen

Construir o comprar ya no es una pregunta con respuesta por defecto, y eso sí es nuevo. La caída del costo de construir es real, el software por asiento está bajo presión real, y una categoría de herramientas que fue seguro licenciar durante una década ya no lo es.

Pero la razón por la que fracasan los proyectos de construcción no cambió. Fracasan porque nadie opera el resultado, porque nunca se acordaron las definiciones, o porque el problema nunca fue software. Las tres eran ciertas en 2015 y las tres son ciertas hoy.

La parte barata se abarató. La parte difícil sigue donde siempre estuvo.

Si quieres que esto se discuta con honestidad contra tu situación real y no contra una tendencia de mercado, para eso es la primera conversación, y cuánto cuesta reemplazar un sistema plantea la cuenta antes de que alguien se comprometa con cualquiera de los dos caminos.