Comprar o construir software en 2027: cómo decidir

Durante treinta años, el software se compró como un traje de confección: talle estándar, y la empresa se acomodaba adentro. Si el sistema pedía un paso más, se agregaba un paso. Si le faltaba un campo, se abría una planilla al costado.

En 2026 apareció el sastre. El 32% de las organizaciones ya dejó de comprar al menos un software o una función porque pudo construirla con IA, según McKinsey. La pregunta ya no es si se puede construir. Es cuándo conviene.

Esta guía sirve para decidirlo en cada compra y en cada renovación: una matriz, un ejemplo de cinco días, la cuenta completa del costo y las reglas para que lo construido no se vuelva un desorden.

El traje de confección ya no es la única opción

Hasta hace poco, una empresa mediana tenía dos caminos. Comprar un software estándar y adaptar su proceso. O pagar un desarrollo a medida: tres a seis meses, un equipo técnico y un presupuesto que casi nunca cerraba.

La IA abrió un tercer camino. Quien conoce el proceso describe lo que necesita y obtiene una herramienta funcionando en días. No una maqueta: una aplicación con pantallas, base de datos, usuarios y permisos.

Los números de 2026 dicen que ya no es un juego de programadores:

• 32% de las organizaciones decidió no comprar al menos un software o función porque podía construirlo con herramientas de IA (McKinsey, State of AI 2026, 1.719 respuestas en 97 países).
• 35% de los equipos que construyen software interno ya reemplazó la función de al menos una herramienta comprada (Retool, 2026 Build vs. Buy Report).
• 51% ya tiene en uso al menos un software propio hecho con IA.
• 78% planea construir más herramientas propias en 2026.

El argumento de fondo no es el precio. Es el ajuste. El software comprado te obliga a cambiar tu proceso. El construido se ajusta a él.

Qué se está reemplazando primero

Nadie está tirando el ERP. Lo que se reemplaza primero es la periferia: las herramientas chicas que cada área pagaba por usuario para resolver un pedazo de su trabajo.

La encuesta de Retool muestra el orden. Porcentaje de encuestados que ya reemplazó cada tipo de herramienta por una propia:

1. Automatización de flujos de trabajo: 35%.
2. Herramientas internas de operaciones: 33%.
3. Tableros e informes: 29%.
4. Gestión de clientes y ventas (CRM): 25%.
5. Formularios y carga de datos: 25%.
6. Seguimiento de proyectos: 23%.
7. Atención al cliente: 21%.

Una advertencia honesta: la muestra son 817 personas que construyen software interno con Retool, 36% de ellas programadores. Gente que ya construye. El dato muestra hacia dónde va la curva, no dónde está el promedio de tu industria.

Lo que comparten todas las categorías de la lista: son procesos donde cada empresa trabaja distinto. Ahí es donde el talle estándar aprieta.

Con qué se construye hoy

Cinco herramientas concentran la conversación. Todas parten de lo mismo: una descripción en lenguaje común.

• Claude Code (Anthropic). El agente que construye y modifica software a partir de una instrucción. Superó los USD 2.500 millones de ingresos anualizados en febrero de 2026. Con Cowork, la misma lógica llega a equipos que no programan.
• Codex (OpenAI). Más de 5 millones de usuarios semanales a junio de 2026. Uno de cada cinco no es programador, y ese grupo crece unas tres veces más rápido que el de los desarrolladores.
• Google AI Studio. Arma aplicaciones completas a partir de una instrucción y las deja listas para usar.
• Cursor. El editor con IA que usan los equipos técnicos para construir y mantener más rápido.
• Replit. Un agente que programa, publica y aloja la aplicación en un mismo lugar.

El dato que importa no es cuál es mejor. Es quién las usa. Cuando uno de cada cinco usuarios de una herramienta de programación no programa, el que construye ya no es solo el área de sistemas. Es la gerente comercial, el jefe de operaciones, la analista de finanzas.

Si querés ver cómo trabaja una de estas herramientas sin escribir código, está explicado en qué es Claude Code y para qué sirve.

La matriz: comprar, construir encima o construir

Toda decisión de software se ordena con dos preguntas.

¿El proceso te diferencia? Si lo hacés igual que cualquier empresa de tu rubro, el talle estándar alcanza. Si es tu forma de vender, de cotizar o de atender, ahí está tu ventaja, y el software estándar la achata.

¿Qué pasa si falla? Hay procesos donde un error es una molestia. Y otros donde es una multa, un sueldo mal pagado o una venta frenada.

Con esas dos preguntas aparecen cuatro casillas:

• Construir (te diferencia, el error se repara): cotizadores, tableros, seguimiento de pedidos, formularios internos, flujos de aprobación. Es donde el traje a medida rinde más.
• Construir encima (te diferencia, el error es grave): el sistema de registro se compra y arriba se construye la capa que es tuya. El ERP guarda los precios; tu cotizador los usa.
• Comprar (no te diferencia, el error es grave): contabilidad, nómina, facturación electrónica, cobros. El uniforme reglamentario no se diseña: se usa el que pide la norma.
• Usar lo que ya pagás (no te diferencia, el error se repara): antes de comprar o construir, revisá si la suscripción de IA o de oficina que ya tenés lo resuelve. A veces la mejor herramienta es una planilla bien hecha.

Y una tercera variable que corta todo: el volumen. Miles de operaciones por día, cientos de usuarios a la vez, disponibilidad las 24 horas. Cuanto más alto, más pesa a favor de comprar.

La regla corta: comprá el uniforme, mandá a hacer el traje.

Un cotizador en cinco días

Un ejemplo ilustrativo, armado con capacidades disponibles hoy. Un distribuidor con 25 vendedores. Cada propuesta se arma a mano: copiar precios del ERP, buscar fotos, pegar casos, calcular descuentos. Horas por propuesta, y cada vendedor con su propia versión.

La gerente comercial conoce el proceso de memoria. No programa. Con una herramienta de construcción con IA, y con el área de sistemas a cargo de las conexiones:

• Día 1. Describe el proceso. La IA arma la primera versión: pantallas, base de datos y usuarios.
• Día 2. Conecta la información. Precios y stock del ERP, clientes del CRM, catálogo y casos de la base de conocimiento.
• Día 3. Suma reglas y marca. Descuentos por volumen, margen mínimo, aprobación de gerencia y la plantilla de presentación de la empresa.
• Día 4. Prueba con tres vendedores. Ajusta textos, diapositivas y reglas según lo que ellos encuentran.
• Día 5. Lo usan los 25. Cada vendedor carga cliente y productos, y en minutos tiene una presentación de ocho diapositivas con precios vigentes.

Fijate dónde cae en la matriz. El cotizador es diferencial: es cómo vende esta empresa. El error se repara: una propuesta se corrige antes de salir. Pero los precios no se tocan, viven en el ERP comprado. Es la casilla "construir encima" en su versión más limpia.

Ningún software estándar de propuestas sabía cuándo esta empresa pide aprobación de la gerencia. Este sí, porque lo escribió la persona que toma esa decisión todos los días.

Si el cuello de botella de tu equipo es armar propuestas, hay un camino todavía más corto: automatizar propuestas comerciales con una Skill de Claude.

El costo que no sale en la demo

Construir la primera versión nunca fue tan barato. Justamente ahí está el riesgo: el precio de entrada esconde el resto de la cuenta.

Un traje a medida necesita arreglos. Con el software pasa lo mismo, y los arreglos son el punto débil de construir:

• Los cambios del negocio. Nueva lista de precios, nuevo impuesto, nuevo producto. Alguien tiene que actualizar la herramienta.
• Los cambios de afuera. El ERP actualiza su conexión, el proveedor de IA cambia un modelo. Lo que andaba deja de andar.
• La persona que lo armó se va. Si nadie más entiende la herramienta, la empresa queda rehén de un archivo.
• Seguridad y permisos. Quién ve qué, quién cambia qué, dónde quedan los datos de los clientes.

No es un problema nuevo. En 2025, los CIOs encuestados por a16z ya advertían que las herramientas internas son difíciles de mantener y que muchas veces no dan ventaja de negocio. La IA abarata construir. Mantener se abarata bastante menos.

Del otro lado, comprar tampoco es un precio fijo. Los proveedores están cambiando cómo cobran. IDC prevé que en 2028 el cobro puro por usuario quede obsoleto y que el 70% de los proveedores pase a cobrar por consumo, por resultado o por otra métrica. Gartner estima que unos USD 234.000 millones, el 20% del gasto en software empresarial, quedan expuestos a los agentes hacia 2030.

La comparación honesta es de costo total, a tres años, en los dos caminos:

• Comprar: licencias por usuario (y su próxima suba), implementación, adaptación del proceso y las planillas que aparecen al costado porque el sistema no llega.
• Construir: horas de quien lo diseña, suscripciones de la herramienta y del modelo, apoyo de sistemas, y un responsable con horas asignadas para mantenerlo.

Si en la columna de construir no hay un nombre con horas asignadas, la cuenta está mal hecha.

Dónde comprar sigue ganando

La inclinación es a construir más. No a construir todo. Hay tres terrenos donde el software comprado sigue siendo la mejor decisión, y lo va a seguir siendo en 2027:

• Procesos regulados. Contabilidad, nómina, facturación electrónica, retenciones. La norma cambia, y el proveedor se ocupa de seguirla para miles de clientes a la vez. Construirlo es heredar esa obligación.
• Sistemas críticos. Si se caen, se frena la empresa: el ERP central, los cobros, el despacho. Ahí se paga por soporte, respaldo y responsabilidad contractual.
• Alto volumen. Miles de operaciones por hora, cientos de usuarios simultáneos, auditoría externa. Sostener eso es un oficio aparte.

Hasta el caso más citado lo confirma. Cuando se dijo que Klarna había reemplazado Salesforce y Workday con IA, su CEO aclaró en 2025 que no: había construido una capa propia de datos y había pasado parte del trabajo a otros softwares comprados. Construyó encima. No tiró el sistema de registro.

Lo regulado se compra. Lo que te hace distinto se construye.

Cómo poner orden antes de que crezca

El riesgo de 2027 no es construir poco. Es construir mucho y sin mapa.

Retool encontró que el 60% de quienes construyen hizo algo fuera de la supervisión del área de sistemas en el último año. Y Gartner prevé que en 2029 el 80% de las aplicaciones nuevas sea desechable a propósito: se usan menos de un año. Va a haber muchas herramientas. La pregunta es si alguien sabe cuáles hay.

Cuatro reglas alcanzan para empezar:

1. Un catálogo. Una lista única de herramientas propias: qué hace cada una, quién la usa, qué datos toca y a qué sistemas se conecta. Si no está en el catálogo, no existe.
2. Un responsable por herramienta. Una persona con nombre que la mantiene, la actualiza y responde si falla. No el que la armó por defecto: el que acepta el cargo.
3. Permisos mínimos. Cada herramienta entra a los sistemas con su propio usuario y solo a lo que necesita. Los datos de clientes no viajan a cuentas personales.
4. Fecha de revisión. Cada seis meses, cada herramienta se mejora, se mantiene o se jubila. Lo desechable está bien, siempre que alguien lo deseche.

El área de sistemas no pierde lugar. Cambia de rol: de construir todo a poner las reglas, conectar los datos y cuidar lo crítico. Pasa de ser el único sastre a ser el jefe del taller.

Empezá por la próxima renovación

No hace falta una estrategia de software nueva para arrancar. Alcanza con la próxima renovación que llegue a tu escritorio.

Antes de firmarla, pasala por la matriz. ¿El proceso te diferencia? ¿Qué pasa si falla? ¿Cuánto volumen mueve? ¿Cuántos usuarios pagás que casi no la usan? ¿Quién mantendría la alternativa construida?

Si las respuestas dicen "comprar", renová tranquilo y negociá mejor. Si dicen "construir", tenés un piloto de cinco días esperando.

La pregunta que importa no es si tu empresa puede construir software. Es cuánto de tu proceso estás dejando que lo diseñe otro.

¿Querés pasar una renovación concreta por la matriz? Hablemos.