Una firma de capital privado estaba realizando la debida diligencia sobre una empresa SaaS. Proceso estándar: evaluar el producto, la posición en el mercado y la defensabilidad técnica. Pero esta vez, el equipo de consultoría añadió un nuevo paso. Tomaron el producto principal de la empresa objetivo y pidieron a un asistente de programación con IA que lo replicara. En pocos días, tenían un prototipo funcional que reproducía el flujo de trabajo principal. El postor se alejó. El prototipo no era de producción y no necesitaba serlo; Demostró que el producto podía reproducirse más rápido de lo que la adquisición podía cerrarse.

Esa noticia proviene de un informe del Financial Times sobre Bain & Company, que ha adoptado la replicación asistida por IA como herramienta de debida diligencia para clientes de capital privado. Llegó a mi bandeja de entrada la misma semana que Retool publicó su Informe de Construcción vs. Compra 2026. Hallazgo principal de Retool: el 35% de los equipos empresariales ya han reemplazado al menos una herramienta SaaS por una build personalizada, y el 78% espera crear más este año.

Para los CTOs que prestan atención, la señal es clara. La economía que hizo que «comprar» fuera el impago seguro durante dos décadas ha cambiado. Pero no se transformaban de forma uniforme, ni completamente. Las organizaciones que lo hacen bien son las que entienden tanto lo que cambió como lo que no.

La propiedad es todo lo que ocurre después del primer despliegue: parches de seguridad, auditorías de cumplimiento, respuesta a incidentes, incorporación de ingenieros que no estaban presentes cuando se escribió el código y mantener el sistema legible a medida que evoluciona. Ese coste no aparece en el presupuesto de construcción.

¿Qué cambió?

Empieza por la economía modelo. A mediados de 2026, los modelos de peso abierto funcionan aproximadamente entre 10 y 12 veces más baratos que los SaaS de frontera para un conjunto creciente de cargas de trabajo comunes: resumen, clasificación, generación de código, extracción de datos. La matemática por transacción que hacía del SaaS la opción obvia para cualquier cosa por debajo de la escala empresarial se ha erosionado.

Los plazos de desarrollo se comprimían al mismo tiempo. Lo que antes tardaba un cuarto de dólar moneda ahora puede ser estructurado en días, y un ingeniero capaz con Claude Code, Github Copilot, Kiro o Codex puede crear una herramienta interna funcional en el tiempo que antes solo se necesitaba para completar la adquisición de proveedores. La duración de la compilación que históricamente justificaba la prima de «compra» se redujo un orden de magnitud para ciertos tipos de carga de trabajo.

Luego los mercados revaloraron el riesgo. En febrero de 2026, más de 285.000 millones de dólares en capitalización borsátil SaaS se evaporaron en una sola semana de ventas de pánico que los analistas bautizaron como la «SaaSocalipsis». Thomson Reuters bajó un 15,8%, LegalZoom un 19,7%. El repricing se trataba de la futura defensabilidad: si tu producto principal puede replicarse en días por un equipo de consultoría que gestiona un agente de codificación, ¿qué está pagando exactamente el comprador?

Los modelos más baratos hacían viable la construcción, el desarrollo más rápido lo hacía práctico y el repricing hacía que la conversación fuera lo suficientemente urgente como para llegar al consejo.

¿Qué no cambió

Aquí es donde la mayoría del entusiasmo de «construir todo» falla.

Eric Hawkins, CTO de Ontra, lo expresó con precisión: «Las matemáticas entre construir y comprar cambiaron. Las matemáticas de mantenimiento no.» Un ingeniero capaz puede preparar en unos días lo que antes llevaba un trimestre, y luego aún necesitas equipos operativos, parches de seguridad y alguien que entienda lo que hace el código dentro de seis meses.

Lo que la IA convirtió en mercancía fue el acto de producir software, no el software en sí. La ventaja competitiva pasó de la capacidad de construir a la capacidad de poseer, operar y evolucionar lo que se construyó.

El coste total de propiedad del software personalizado sigue incluyendo mantenimiento, actualizaciones de seguridad, auditorías de cumplimiento, incorporación de nuevos miembros del equipo, gestión de casos límite que el creador original no previó y la carga cognitiva de entender el código que se produjo a velocidad de IA. Ese último coste ya tiene un nombre: deuda de comprensión. Cuando nadie en el equipo puede explicar por qué un sistema funciona como funciona, porque se generó más rápido de lo que el conocimiento institucional pudo formarse, has cambiado la dependencia del proveedor por opacidad interna.

El informe de Retool ocultó el hallazgo más importante en un gráfico secundario: de los equipos que reemplazaron el SaaS por montajes personalizados, el 41% informó que dedicaron más tiempo de ingeniería al mantenimiento de lo que esperaban. Las sorpresas no fueron exóticas: parches de seguridad que el fabricante solía absorber, casos límite que solo aparecen a gran escala, ingenieros que se unen tras la construcción inicial sin ningún modelo mental de por qué el sistema funciona como funciona. Si tu organización carece de la disciplina de gobernanza para mantener lo que construye, lo más barato de construir se convierte en más caro de poseer.

El nuevo marco decisional

El error es asumir que la IA cambió cada decisión de construir o comprar por igual. No fue así. La interrupción es real pero desigual, y la respuesta determina dónde cae la carga de trabajo.

Un artículo de investigación de principios de este año, «The Buy-or-Build Decision, Revisited», publicado en arXiv y que ahora circula en círculos de estrategia empresarial, analizó la tesis de la revalorización del mercado en diferentes categorías de software empresarial y encontró la misma desigualdad. Surgen tres agrupaciones, y se corresponden perfectamente con lo que veo en la práctica.

Las cargas de trabajo commodity son utilidades donde el proveedor no aporta diferenciación: paneles internos, pipelines de notificaciones, flujos de trabajo de transformación de datos, aplicaciones CRUD simples. Estos son los candidatos de construcción más fuertes en 2026. El proveedor de SaaS siempre cobraba un margen por alojar y mantener algo que tu equipo podría haber construido; La diferencia es que ahora tu equipo sí puede, en días en vez de meses. Si el valor de la herramienta es puramente funcional, moviendo datos de A a B o enviando alertas cuando se superan los umbrales, el caso de construcción es convincente.

Las cargas de trabajo estratégicas son las aplicaciones que diferencian la ventaja competitiva: personalizaciones de CRM que codifican tu proceso de ventas, pipelines de análisis que generan insights propietarios, herramientas orientadas al cliente que definen la experiencia de tu producto. Estos siempre fueron los casos de construcción más sólidos en teoría, y el problema era que montarlos llevaba demasiado tiempo y costaba demasiado. La IA colapsó ambas restricciones. Aquí es donde la tesis del repricing es más fuerte, porque si tu ventaja competitiva reside dentro de la plataforma de un proveedor, el proveedor es el dueño de tu diferenciación. La economía ahora te permite recuperarla.

Las cargas de trabajo reguladas son los sistemas críticos para la misión que conllevan una alta carga de cumplimiento: ERP, banca central, historiales electrónicos de salud, gestión de identidad. La evidencia apunta consistentemente a que estos permanecen predominantemente en el ámbito de compra, y no porque sea imposible construirlos. La infraestructura de cumplimiento, certificación y auditoría que rodea estos sistemas es un coste que no se comprime con la IA. Los requisitos regulatorios no se abaratan porque tu agente de codificación sea más rápido, y la carga de gobernanza de poseer estos sistemas suele superar el coste de licencia de comprarlos.

Lo que la mayoría de los defensores de «construir todo» no ven es que las categorías no están fijas. Un panel de control de materias primas adquiere una carga de cumplimiento en el momento en que empieza a alimentar un informe regulatorio, por lo que la decisión debe revisarse a medida que cambia el papel del sistema.

El requisito previo de gobernanza

La IA también colapsó el coste de la experimentación. Un equipo puede prototipar internamente en dos o tres semanas y comparar el resultado con la alternativa SaaS, convirtiendo «comprometerse a construir o comprometerse a comprar» en «probar si construir esto es viable, a bajo coste, antes de decidir.» Pero los experimentos más baratos solo importan si puedes evaluar lo que has construido, y evaluar lo que has construido requiere la disciplina para mantenerlo.

Aquí es donde este argumento se conecta con algo sobre lo que llevo escribiendo dos años: las organizaciones posicionadas para beneficiarse del cambio de construir contra comprar son las que tienen la fuerza de gobernanza para mantener lo que construyen. El acceso barato a herramientas de codificación por IA es casi universal a estas alturas, así que no decide nada.

La historia de Bain PE va en ambos sentidos. El postor se retiró porque el producto del objetivo podía replicarse, y ese mismo postor habría dejado una empresa que construyó todo con IA y no pudo explicar cómo funcionaba nada de eso. Ahora la defensabilidad significa poder mantenerla, ampliarla, protegerla y explicarla bajo auditoría, lo cual es una afirmación sobre la organización más que sobre el código.

Los equipos sin disciplina de desarrollo estructurada construirán más rápido pero enfrentarán peores: la deuda de comprensión se acumula, las revisiones de arquitectura se saltan y lo que funcionó en una demo falla bajo carga real.

Por eso escribí en una publicación anterior que las organizaciones preparadas para la gobernanza adoptarán primero el desarrollo impulsado por IA. La misma tesis se aplica al cambio de construir contra comprar: las organizaciones con músculo de gobernanza existente (procesos de gestión del cambio, prácticas de revisión de arquitectura, disciplina de seguridad como restricción, puertas estructuradas de calidad) son las que realmente pueden captar el valor de la construcción más barata. Todos los demás construirán más rápido y se arrepentirán al mismo ritmo.

Qué significa esto en la práctica

La auditoría es lo primero. Revisa el portafolio actual de proveedores y ordélgalo: qué herramientas son utilidades de consumo en las que el proveedor no aporta nada más allá del alojamiento, cuáles codifican la diferenciación competitiva que la organización debería poseer y cuáles conllevan obligaciones de cumplimiento que hacen que la propiedad sea más cara que la licencia.

Luego cambia una herramienta común, no cinco. Demuestra que el equipo puede construirlo y mantenerlo, y mide el coste total de propiedad durante seis meses en lugar de al final de la fase inicial de construcción. Si los costes de mantenimiento superan la suscripción que reemplazó, o bien la categorización fue incorrecta o el equipo aún no tiene la disciplina para poseer software personalizado.

La infraestructura de mantenimiento debería estar lista antes de que empiece la construcción, y esta es la parte que nadie pone en una diapositiva: prácticas de revisión de arquitectura, rituales de comprensión de código, escaneo de seguridad como restricción de desarrollo, disciplina documental, procedimientos de incorporación para quienes se incorporan tras la construcción.

Comprar también sigue siendo la respuesta correcta para una parte significativa de la cartera. El objetivo es dejar de impagar en ninguna dirección: dejar de comprar para cargas de trabajo donde construir ahora es más barato y estratégicamente superior, y dejar de fabricar para cargas donde el cumplimiento y el mantenimiento hacen que la propiedad sea más cara que la licencia.

Ni pánico ni despido

La ansiedad del mercado a principios de 2026 produjo reacciones erróneas en ambas direcciones. Algunos CTOs entraron en pánico y empezaron a reemplazarlo todo por construcciones personalizadas, luego descubrieron que construir más barato no significa tener más barato. Otros descartaron por completo el cambio, insistiendo en que «SaaS está bien» mientras sus equipos creaban discretamente aplicaciones en la sombra porque las herramientas autorizadas eran insuficientes.

Lo que el momento exige es más lento y menos dramático: una reevaluación categoría por categoría de dónde construir ahora supera a comprar, acompañada de una evaluación honesta de si tu organización puede ser dueña de lo que construye. La economía se movió. Si tu metodología se movió con ellos es la parte que sigues controlando.

La ventaja es para las organizaciones que saben exactamente qué merece ser apropiado.

Ricardo