Comprar software da paridad. Solo lo que construye lo distingue.

La pregunta llega casi siempre de la mesa de la administración, y viene envuelta en costo: ¿construir nuestro propio software o suscribir un SaaS que ya existe? Formulada así, la respuesta parece una hoja de cálculo. No lo es. Es una pregunta sobre dónde vive su ventaja. Comprar software resuelve lo que es común y le entrega lo que el mercado entero ya tiene. Construir a medida es para el núcleo que lo distingue. Lo que es igual no lo coloca por delante de nadie, y es por ahí que esta decisión debe leerse antes de leerse por el precio.

Lo que realmente se está decidiendo

El ingeniero Martin Fowler propone una división simple y útil. Hay software utilitario, que todo el mundo necesita y que solo tiene que funcionar, y hay software estratégico, aquel en que la forma en que hace una función es parte de lo que lo vuelve mejor que la competencia. La nómina es el ejemplo clásico de utilitario: nadie gana clientes por procesar salarios de manera más ingeniosa. Y es de aquí que sale la regla de comprar o construir.

Since the definition of utility is that there's no differentiator, the obvious thing is to go with the package. [...] For a strategic function you don't want the same software as your competitors because that would cripple your ability to differentiate. Martin Fowler, Utility Vs Strategic Dichotomy, 2019

No es una idea solitaria. Geoffrey Moore, en Dealing with Darwin, separa el core, aquello que crea preferencia de compra, del context, todo lo que hace falta hacer para mantenerse en el mercado pero que no distingue, y recomienda minimizar o externalizar el context para liberar a las mejores personas para el core. Gartner ordena el mismo instinto en una arquitectura de tres capas: sistemas de registro, que duran una década y solo tienen que estar correctos; sistemas de diferenciación, que codifican lo que la empresa hace diferente; y sistemas de innovación, cortos, para probar oportunidades nuevas. Tres lenguajes, una conclusión: se compra el registro, se construye aquello que diferencia.

Comprar le da paridad, y a veces es lo que basta

Conviene decir lo que el SaaS hace bien, porque lo hace. Para contabilidad, correo electrónico, procesamiento de salarios o un CRM en fase inicial, comprar es la decisión correcta y casi siempre la más barata. No vale la pena construir aquello en que la diferencia no cambia nada para el cliente. Pero hay un precio que no está en la factura, y no es el financiero. Cuando usted suscribe la misma herramienta que suscriben los competidores, hereda la capacidad y hereda también los límites. El sistema fue diseñado para servir a mil empresas, no a la suya, y la suya acaba por moldear el proceso a la herramienta. En context, eso es aceptable. En core, es entregar la diferencia a un proveedor que la vende igual al vecino de al lado.

El precio de tarifa no es el costo

El segundo engaño es creer que el costo del SaaS es el número de la tabla. El gasto mundial en aplicaciones SaaS debe acercarse a los 300 mil millones de dólares en 2025, por encima de poco más de 250 mil millones en 2024, según Gartner. No es el volumen del mercado lo que interesa aquí, es lo que esconde dentro de cada empresa que suma ese total.

Tres costos raramente entran en la cuenta por adelantado. El primero es que el precio sube. El índice de Vertice, una plataforma que ayuda a empresas a negociar compras de software, registró una subida media de los precios de SaaS del orden del 12% en un período de doce meses, contra 6% en 2019. Es un valor con interés propio, y vuelvo a él justo a continuación, pero la dirección es conocida por quien renueva contratos: la mensualidad que firmó no es la mensualidad que va a pagar dentro de tres años.

El segundo es que se paga por lo que no se usa. Según el índice de gestión de SaaS de Zylo, las empresas usan en promedio cerca de la mitad, 49%, de las licencias que compran, con un desperdicio medio del orden de 18 millones de dólares por año en licencias paradas. El tercero es estructural y es el que menos se ve: el SaaS es un gasto recurrente que escala con cada puesto y con cada integración, y que sigue saliendo de la cuenta todos los meses mientras la empresa exista. Construir tiene un costo alto por adelantado y después amortiza. Comprar tiene un costo bajo por adelantado y después compone, para siempre.

El límite honesto de estos números

Aquí hay que ser riguroso sobre la fuerza de esta prueba. Zylo vende gestión de SaaS y Vertice vende negociación de software: las dos tienen interés en que el desperdicio y la inflación parezcan grandes. La muestra de Zylo son empresas que ya contrataron gestión de SaaS, es decir, quien ya tenía exceso que controlar, y se inclina hacia grandes organizaciones, lo que empuja la media de los 18 millones hacia arriba. El desperdicio de licencias es una falla de gestión, no un defecto inherente del modelo, y un aumento de precio anunciado no es el aumento efectivamente pagado por quien negocia. Nada de esto prueba que comprar es malo. Prueba que el costo del SaaS no es el número de la tabla, y que quien decide con el número de la tabla decide con información incompleta.

La economía que la inteligencia artificial cambió

Hay una razón nueva para reabrir esta decisión en 2026, y es del lado de construir. El trabajo de rutina del desarrollo, el código repetitivo, las pruebas, el andamiaje que se monta antes de empezar la parte difícil, se volvió más barato. En un ensayo controlado con 95 programadores, el grupo con acceso a GitHub Copilot completó una tarea 55,8% más rápido que el grupo sin la herramienta.

The treatment group, with access to the AI pair programmer, completed the task 55.8% faster than the control group. Sida Peng, Eirini Kalliamvakou, Peter Cihon e Mert Demirer, The Impact of AI on Developer Productivity, 2023

La tarea era construir un servidor HTTP en JavaScript, un ejercicio autónomo y bien definido, exactamente el tipo de trabajo que llena las primeras semanas de cualquier proyecto. Si la mitad de ese trabajo se vuelve más rápida, el costo fijo de construir el núcleo que lo distingue baja. Lo que antes solo compensaba a una escala grande pasa a compensar más temprano. Es este el cambio concreto: construir a medida dejó de ser un exclusivo de quien tiene un equipo de decenas de personas.

Lo que esto no prueba

Esta es la parte que separa un razonamiento de un argumento de venta, y es la parte que corta contra el entusiasmo fácil. La ganancia del 55,8% fue medida en una tarea aislada, desde cero, hecha por profesionales reclutados para el ensayo, en un estudio de la propia GitHub. El estudio mide la velocidad en una tarea, no mide la calidad, el mantenimiento ni el resultado de un producto. Y cuando se mide precisamente el otro caso, el de trabajar dentro de un código grande que ya existe, el resultado se invierte.

When developers are allowed to use AI tools, they take 19% longer to complete issues—a significant slowdown that goes against developer beliefs and expert forecasts. METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, 2025

En este ensayo de 2025, dieciséis programadores experimentados trabajaron en repositorios que conocían desde hacía años, en 246 tareas reales, y permitir la IA los hizo demorar 19% más. El dato más incómodo no es la ralentización, es la percepción. Los mismos programadores habían previsto que la IA los aceleraría 24% y, después de que la experiencia los atrasó, siguieron convencidos de que los había acelerado 20%. La herramienta hace sentir rápido, y la sensación no coincide con el cronómetro.

Y construir carga riesgo, incluso cuando se vuelve más barato. El CHAOS Report de 2020 del Standish Group coloca 31% de los proyectos como exitosos, 50% comprometidos por plazo o presupuesto y 19% fallidos. El propio informe es criticado por académicos, que apuntan que la muestra es propietaria y que sus definiciones, basadas solo en la precisión de las estimaciones, sesgan los números, y por eso se lee por la dirección y no por el valor exacto: construir desde cero es una apuesta que se presupuesta con margen de error, no un ahorro garantizado. La conclusión honesta no es construir todo. Es que la IA bajó el costo de construir lo que importa, y no la probabilidad de errar cuando se construye lo que no importaba.

Dónde queda la línea, en la práctica

Dicho esto, la decisión deja de ser comprar o construir y pasa a ser dónde trazar la línea, empresa a empresa. La respuesta práctica es híbrida, y la prueba es una sola pregunta: ¿este sistema codifica aquello que hace que lo elijan a usted? Si la respuesta es no, se compra. La contabilidad, el correo, los salarios, el CRM mientras la empresa es pequeña, la videoconferencia: es context, y el context se compra hecho y barato. Si la respuesta es sí, se construye. El motor operativo que nadie en el mercado hace como usted, la lógica de precio o de logística que es su ventaja, el cumplimiento de una regla específica de su sector que ningún paquete genérico cubre sin obligarlo a ser igual a todos: es core, y el core no se alquila.

Hay una señal que decide muchas de estas líneas. Cuando un paquete de estantería lo obliga a cambiar su proceso para caber en él, y ese proceso es precisamente lo que lo distingue, usted está pagando para volverse igual a la competencia. En context, moldearse a la herramienta es sensato y ahorra tiempo. En core, es comprar la paridad que debería estar evitando.

Lo que queda en el balance

Al final, la diferencia entre comprar y construir es la diferencia entre un gasto y un activo. El software que usted compra sale de la cuenta todos los meses y no es suyo: es una capacidad alquilada, igual a la que el competidor alquila en la puerta de al lado. El software que codifica lo que lo distingue queda, se capitaliza y trabaja para usted después de pagado. Existimos para convertir la percepción en activo financiero, y la arquitectura tecnológica que sustenta esa percepción obedece a la misma regla. Lo que es igual no tiene autoridad, y lo que es igual tampoco entra en el balance como valor. Entra como costo recurrente.

Fuentes

Cada número de este artículo ha sido verificado en la fuente primaria. Donde la fuente no sustenta la lectura corriente, lo decimos en el cuerpo del texto.

1. Martin Fowler, Utility Vs Strategic Dichotomy, martinfowler.com, 2019. martinfowler.com/bliki/UtilityVsStrategicDichotomy.html
2. Geoffrey A. Moore, Dealing with Darwin (Portfolio, 2005), el modelo core vs context. en.wikipedia.org/wiki/Dealing_with_Darwin
3. Gartner, Pace-Layered Application Strategy (sistemas de registro, diferenciación e innovación). gartner.com/en/documents/3297020
4. Gartner, previsión de gasto mundial en SaaS (~250 mil millones USD en 2024, ~300 mil millones en 2025), vía CIO Dive, 2024. ciodive.com/news/cloud-spend-growth-forecast-2025-gartner
5. Zylo, 2024 SaaS Management Index (utilización media de 49%; ~18 millones USD de desperdicio medio anual). zylo.com/news/2024-saas-management-index
6. Vertice, SaaS Inflation Index (aumento medio ~12% en doce meses, contra 6% en 2019), vía CFO Dive, 2023. cfodive.com/news/saas-prices-jumped-vertice
7. Sida Peng, Eirini Kalliamvakou, Peter Cihon e Mert Demirer, The Impact of AI on Developer Productivity: Evidence from GitHub Copilot, arXiv 2302.06590, 2023. arxiv.org/abs/2302.06590
8. METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, 2025. metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study
9. The Standish Group, CHAOS Report 2020: Beyond Infinity (31% exitosos, 50% comprometidos, 19% fallidos), con la crítica de Eveleens y Verhoef, IEEE Software, 2010. reseña del informe