No todo debe ser SaaS: cómo decidir qué software merece ser propio
Tiempo de lectura: 6 minutos
Durante años, la regla ha sido cómoda: si existe un SaaS razonablemente bueno, se compra. No se desarrolla internamente, no se "reinventa la rueda", no se dedica equipo propio a construir algo que un proveedor ya vende como servicio. Y en muchos casos esa lógica sigue siendo correcta — no tiene sentido construir tu propio Zoom.
Pero la IA generativa obliga a revisar una pregunta que parecía cerrada: ¿qué deberías seguir comprando y qué capacidades merece la pena construir o evolucionar tú mismo? No es una pregunta menor, y tampoco tiene una respuesta cómoda tipo "todo SaaS" o "ya se puede hacer todo con IA". Las dos son formas de no pensar.
¿Qué mantra ya no encaja del todo?
"Si no eres una empresa de software, no desarrolles software" ha sido durante una década el consejo dominante: externaliza lo técnico, compra herramientas estándar, concentra tus recursos en el negocio.
El problema es que esa frase separa dos mundos que en la práctica ya están mezclados. Hoy, buena parte de tus decisiones de negocio viven dentro de sistemas de software: reglas de pricing, segmentación de clientes, flujos de aprobación, priorización de incidencias, atención al cliente, cumplimiento normativo. Puedes tener tu estrategia en una presentación muy bonita, pero muchas veces la estrategia real está codificada en las herramientas que usa tu equipo cada día.
Por eso la pregunta correcta no es "¿nos sale más barato comprar este SaaS o desarrollar algo propio?". Es esta otra: ¿esta capacidad es lo bastante importante como para que queramos entenderla, adaptarla y evolucionarla desde dentro?
El software no es solo una herramienta: es una forma de decidir
Cuando compras un SaaS no compras solo funcionalidades. Compras también una forma concreta de trabajar: sus flujos, sus permisos, sus informes, su roadmap, su ritmo de cambio. Si tu proceso es estándar, eso es una ventaja real — el proveedor ya empaquetó buenas prácticas y reparte el coste de mantenimiento entre miles de clientes.
Pero cuando el proceso no es tan estándar, pasa lo contrario: la organización empieza a adaptar su forma de trabajar a la herramienta, aunque la herramienta no refleje bien cómo quiere competir. Los cambios importantes acaban dependiendo de un ciclo de presupuesto anual, de una negociación con el proveedor o de un ticket que entra en un roadmap que no controlas. El software deja de acelerar y se convierte en una frontera invisible: no impide trabajar, pero limita la velocidad con la que la organización aprende y decide.
Idea clave — El problema no es externalizar una herramienta. El problema es externalizar la capacidad de entender y evolucionar una parte importante de tu modelo operativo.
Cuando una capacidad se desarrolla o evoluciona internamente, negocio, tecnología y operaciones tienen que hablar con más frecuencia. Es incómodo, porque obliga a decisiones más explícitas — pero también acelera la ejecución de la estrategia, porque una organización que no puede modificar sus sistemas tampoco puede modificar fácilmente su forma de trabajar.
La IA abarata construir, pero no elimina la ingeniería
Aquí es donde conviene ser precisos y no venderte humo. La IA generativa reduce de verdad el coste de escribir código, generar pruebas, documentar o crear prototipos — el estudio de Microsoft Research con GitHub Copilot midió una tarea controlada completada un 55,8% más rápido con un asistente de IA que sin él (Microsoft Research, 2023). Ese dato es real y lo he vivido yo mismo: así sustituí buena parte del stack SaaS de ITNOVE por sistemas propios, con números concretos de ahorro.
Pero cuidado con el salto de "generar código más rápido" a "construir software fiable". GitLab publicó en 2026 un informe sobre 1.528 desarrolladores y responsables técnicos en el que el 80% adoptó herramientas de IA más rápido que sus políticas de gobierno, y el 92% reporta retos reales gobernando código generado por IA. Generar es fácil. Producto, arquitectura, seguridad, datos, soporte y mantenimiento siguen siendo ingeniería — y ninguno de esos frentes se resuelve solo porque el código salga más rápido. Ya hablamos de esto en clave de contexto y harness en ingeniería de contexto, y de por qué generar no es lo mismo que crear impacto en generar código con IA es fácil; crear impacto, no tanto.
¿Qué lado oculto tiene el SaaS: la dependencia elegante?
Comprar SaaS no elimina el riesgo — muchas veces lo cambia de sitio. Ya no está tanto en mantener servidores, sino en depender de contratos, integraciones, formatos propietarios y el roadmap de otra empresa. El vendor lock-in rara vez se ve al principio: aparece cuando quieres cambiar, y descubres que los datos no salen limpios, que los informes críticos viven dentro del proveedor y que migrar sale mucho más caro de lo previsto.
Y el dato que probablemente más debería preocupar a un comité de dirección esta década: Gartner estima que hasta 234.000 millones de dólares de gasto en software empresarial —cerca de un 20% del gasto SaaS— están expuestos de aquí a 2030 al llamado agentic arbitrage: agentes de IA que completan tareas atravesando varios sistemas, sin que nadie tenga que abrir la pantalla del proveedor. El SaaS no va a desaparecer, pero el modelo de "licencia por asiento" que lo sostiene sí está cambiando de base.
¿Por qué la opción más interesante casi nunca es "todo o nada"?
"SaaS o software interno" es una mala pregunta. La buena pregunta es: ¿qué parte del sistema debe ser estándar y qué parte debe ser propia?
Muchas organizaciones no necesitan sustituir su CRM o su ERP. Necesitan construir una capa propia alrededor: datos independientes, automatizaciones específicas, un asistente interno con IA, reglas de negocio que sí son diferenciales. Mantener el SaaS para lo estándar, dejar de aceptar que toda la lógica de negocio viva dentro de la herramienta de otro. Eso es exactamente lo que hicimos con la ingeniería de agentes de IA sin programar: no sustituir el sistema base, sino ponerle una capa propia encima donde de verdad importa.
Una regla práctica que funciona en la mayoría de comités:
- Mantén el SaaS cuando el proceso sea estándar, el encaje sea bueno y los datos salgan sin fricción.
- Ve a híbrido cuando el SaaS siga siendo útil, pero los datos, el reporting o ciertos flujos sean demasiado importantes como para depender por completo del proveedor.
- Explora una solución interna cuando el proceso sea diferencial, el encaje sea bajo, el coste oculto sea alto y exista capacidad interna real para mantener lo que construyas.
Y una advertencia que conviene decir en voz alta: si tu organización no tiene todavía capacidad de producto, arquitectura o mantenimiento, sustituir SaaS por software interno no es ganar independencia — es cambiar una dependencia externa por deuda técnica propia. La pregunta final no es "¿podemos construirlo?". Es "¿podemos convertirlo en una capacidad sostenible de la organización?". Antes de lanzarte, merece la pena leer cuándo un agente de IA aporta valor de verdad y cuándo es humo.
¿Por qué la decisión madura no es de presupuesto, sino de estrategia?
Las decisiones sobre SaaS suelen tomarse en ciclos largos: presupuesto anual, renovación de licencia, negociación con el proveedor. Tiene sentido para controlar el gasto, pero es demasiado lento si quieres cambiar tu modelo comercial o meter IA en un proceso interno de verdad.
Ver el software como un activo no significa querer construirlo todo tú. Significa decidir de forma consciente qué capacidades quieres controlar, cuáles prefieres comprar, y cómo quieres que tu organización aprenda y decida a través de sus propios sistemas. Ese es el cambio real que trae la IA — no que construir sea gratis, sino que ya no hay excusa para no volver a hacerte la pregunta.
¿Por dónde empezar con tu caso concreto? Hemos montado un evaluador rápido justo debajo — pon tus respuestas y te da una primera lectura en menos de dos minutos.
Etiquetas: IA · SaaS · Build vs Buy · Estrategia digital · Arquitectura empresarial