El SaaS cree que le compran porque el cliente no sabe construir software. Nunca fue así: era un cálculo. Y la IA acaba de cambiarle las variables de ese cálculo.
En julio de 2026, Bloomberg informó sobre una presentación interna filtrada de Starbucks. La cadena gasta cerca de 400 millones de dólares al año en software y ahora está creando sus propias herramientas con IA para reemplazar el sistema de inventarios de Microsoft y la plataforma de mantenimiento de IBM. El punto de venta de Oracle ya estaba en camino de ser reemplazado.
Este año fiscal, Starbucks espera ahorrar unos 10 millones de dólares en software, lo que representa el 2.5% de su gasto total.
La reacción del mercado fue mucho mayor que ese ahorro: IBM bajó 3%, Salesforce 4% y ServiceNow 3,5%.
Pensemos en ese último dato: una cadena de cafeterías anunció que haría su propio sistema de mantenimiento y ServiceNow perdió 3.5% de su valor.
NOTA: cifras de mercado tomadas de Forbes (Sandy Carter, 12 jul. 2026).
La respuesta de la industria
Algunos llaman a esto la 'Saaspocalypse'. Bill McDermott, CEO de ServiceNow, respondió de forma directa: “It’s nonsense.” Una tontería.
Hay que tomarlo en serio, porque McDermott no es ingenuo y su argumento tiene peso. Además, en esa misma charla, admitió algo que pocos notaron:
“I see feature companies and perhaps some functional companies actually being eaten by AI because we’re becoming the great consolidator.”
Compañías de feature, y quizás algunas funcionales, serán absorbidas por la IA. Y para dejar claro su punto:
“We are not in a SaaS neighborhood.”
En otras palabras, el principal defensor de la categoría ya aceptó que la frontera está cambiando. Ahora discute de qué lado de la línea queda su empresa.
Así que la pregunta ya no es si el cambio está pasando, sino dónde está esa línea. Y ahí es donde gran parte de la industria se está evaluando mal.
Antes de seguir: Starbucks fracaso en esto hace dos meses
Prefiero decirlo yo antes de que lo mencione alguien más.
En septiembre de 2025, Starbucks lanzó NomadGo, una herramienta de inventario con visión computacional, en 11.000 tiendas. Prometía una precisión del 99% y conteos ocho veces más rápidos que los de una persona. Pero en la práctica, confundía los tipos de leche, omitía productos en los estantes y hacía más lento el trabajo de los baristas. En mayo de 2026, cancelaron el programa y volvieron al conteo manual.
Ese escepticismo está justificado. Pero la diferencia es importante: NomadGo era una herramienta de terceros para un proceso que no estaba bien resuelto. Ahora, el software es interno, de back-office, y se basa en procesos que la empresa conoce a fondo.
La lección que aprendieron hace este segundo intento interesante: si pones IA en un proceso roto, solo amplificas el error. Lo difícil nunca fue escribir el código, sino entender el proceso. Ningún proveedor puede darte eso listo.
La complejidad del SaaS no es la que el cliente tiene que replicar
Aquí hay un punto que pocos mencionan: gran parte de la complejidad de una empresa SaaS no radica en la lógica de negocio de su aplicación, sino en todo lo necesario para operarla como un servicio global.
Una empresa SaaS no solo desarrolla software. Mantiene una enorme cantidad de código, procesos e infraestructura para desplegar, monitorear, asegurar y actualizar un servicio que debe funcionar simultáneamente para miles de clientes distintos. Actualizaciones continuas sin romperle a nadie. Aislamiento entre tenants. Cumplimiento en múltiples jurisdicciones. Niveles de servicio consistentes en múltiples geografías.
Esa carga es real y muy grande. Pero es el costo de ser multi-tenant, no el de resolver el problema en sí.
Cuando una organización crea una aplicación para sí misma, solo tiene un cliente: su propio negocio. Un solo modelo de datos, un solo calendario de cambios y un solo conjunto de reglas de cumplimiento. Debe operar, actualizar y proteger ese software, y hacerlo bien. Pero no necesita construir el 60 o 70 por ciento de la ingeniería que solo existe porque el proveedor vende lo mismo a todos al mismo tiempo.
Cuando un proveedor revisa su backlog y piensa “esto es demasiado difícil para que un cliente lo construya”, muchas veces está considerando tareas que el cliente, en realidad, no necesita realizar.
Entonces, ¿por qué compraron SaaS?
Tampoco es que los clientes empiecen desde cero. El problema nunca fue la falta de capacidad, sino el de enfoque.
Las grandes organizaciones nunca han clasificado todo el software de la misma manera. Distinguen entre software de diferenciación, que les permite competir, atender mejor o moverse más rápido, y software de operación común. El primero, históricamente, se ha construido internamente. Por ejemplo, uno de mis clientes, uno de los tres bancos más grandes de Estados Unidos, creó su propia plataforma digital para casi 100 millones de personas, de misión crítica, en varios centros de datos, con ruteo del usuario a la instancia más cercana. Otro, uno de los bancos más grandes de Sudamérica, replicó esa arquitectura para más de 30 millones de personas.
También hay una prueba estructural: si las corporaciones no supieran construir software sofisticado, no existiría el mercado que conocemos para bases de datos empresariales, observabilidad, plataformas cloud, middleware, ciberseguridad ni open source.
Lo que compraron fue lo otro. Todos necesitan ERP, CRM, gestión documental, finanzas, recursos humanos y administración de contratos: funciones necesarias pero comunes, que deben existir para operar y cumplir, pero que no son la razón por la que una empresa gana en su mercado. Durante años, no asignar a tus mejores ingenieros a construir eso fue una decisión lógica. No porque no pudieran, sino porque no valía la pena.
Y ahí está el punto: “no vale la pena” no es una característica del software, es un cálculo. Y los cálculos cambian cuando varían los factores.
Eso es justo lo que hizo Starbucks. Nadie en la empresa descubrió de repente que sabía programar. Simplemente, alguien volvió a hacer las cuentas.
Lo que realmente cambia con la IA
Lo que cambia con la IA no es la capacidad de construir, sino el costo marginal de hacerlo.
Eso cambia la frontera entre comprar y construir y la desplaza hacia abajo en el mercado. Aquí es donde muchos se confunden: los bancos que mencioné antes siempre pudieron construir, con IA o sin ella. Nadie duda de que JPMorgan puede hacerlo. Lo nuevo es que ahora esa decisión empieza a tener sentido para una cadena de cafeterías, y pronto para una empresa de 800 empleados con seis ingenieros que hace tres años ni lo habría pensado.
El límite superior no cambió, pero el inferior sí.
Y fíjate que Starbucks no está creando su ventaja competitiva. Está desarrollando inventario y mantenimiento: software de operación común, la categoría que se suponía que era territorio seguro del SaaS. La frontera no se mueve hacia lo estratégico, sino hacia lo rutinario.
El mejor argumento en contra, y por qué no alcanza
Volvamos a McDermott, porque su argumento merece ser presentado con claridad, no como una caricatura.
Su tesis es que la IA sola no basta: “AI thinks, but workflow acts.” La IA piensa, el flujo de trabajo actúa. “You can’t just say, ‘Here’s the model. Good luck running your company with it.’” Un modelo sin contexto de datos, sin gobierno ni orquestación es lo que él llama “expensive advice”: consejos caros.
Tiene razón. Y hay una versión aún más fuerte de ese argumento: el costo del software no está en escribirlo, sino en mantenerlo durante diez años. Escribir la primera versión es lo barato, y justo eso es lo que la IA hace más fácil. Lo caro viene después: la rotación del equipo, el ingeniero que se va y era el único que entendía el módulo, el cambio regulatorio que obliga a rehacer la lógica fiscal, la deuda técnica que nadie prioriza. Nada de eso desaparece solo porque un agente escriba código más rápido. Varias empresas que construyan por entusiasmo lo van a descubrir por las malas.
Pero ese argumento cubre menos de lo que parece, y McDermott lo sabe. Funciona donde el costo de mantener el software es realmente alto y constante: orquestar decenas de sistemas, cumplir con regulaciones complejas, cambios normativos frecuentes, datos compartidos entre organizaciones y operación global real. Ese es el terreno que reclama para ServiceNow, y es un reclamo válido. Pero no cubre todo lo demás.
Hay un detalle del día de la noticia que lo explica mejor que cualquier argumento: mientras IBM, Salesforce y ServiceNow caían, Microsoft apenas se movió. Y Microsoft era una de las empresas cuyo software estaba siendo reemplazado. La diferencia es que gana de ambos lados: vende la aplicación que se va y también la infraestructura en la nube sobre la que se construye el reemplazo.
Ahí está la línea, y no la trazó un analista, sino el mercado en una sola tarde. La infraestructura profunda no está en riesgo. La capa de aplicaciones sí.
¿Y si los números dicen lo contrario?
Hay que ser honestos con los datos, porque ahora mismo no me dan la razón.
ServiceNow cerró su segundo trimestre de 2026 con 3.880 millones de dólares en ingresos por suscripción, un 24,5% más que en el mismo trimestre del año anterior. Sus productos de IA superaron por primera vez los mil millones de dólares en valor anual de contratos. Los despliegues agénticos se multiplicaron por 9 en 9 meses. La acción subió un 7% tras el reporte. Si la Saaspocalypse llegó, no aparece en ese estado de resultados. Y del lado de Starbucks, diez millones sobre cuatrocientos es un error de redondeo.
Pero veamos la desproporción: IBM perdió miles de millones en capitalización por un ahorro anunciado de solo 10 millones. ServiceNow llegó a caer casi un 39% mientras crecía más de un 20% al año.
El mercado no está valorando la transacción, sino el precedente.
Además, los ingresos por suscripción son un indicador atrasado: reflejan contratos firmados hace uno, dos o tres años, cuando los clientes no tenían otra opción realista. El software de Starbucks ni siquiera existe todavía; saldrá a finales de 2027, si pasa las pruebas. Esto no se verá en el próximo trimestre, sino en la renovación de 2028, cuando alguien de finanzas pregunte por qué siguen pagando lo mismo por algo que su equipo ya sabe hacer.
Un buen trimestre no contradice un cambio estructural. Solo muestra que aún no ha llegado.
La pregunta incómoda
Y hay otro frente, por si fuera poco: muchos ingenieros ya están aprendiendo a trabajar con agentes de código, lo que también reduce la barrera de entrada para nuevos competidores con costos mucho más bajos. El incumbente no solo defiende su posición frente a clientes inexpertos, sino también por ambos lados al mismo tiempo.
Todo esto obliga a las empresas de software a hacerse una pregunta incómoda: ¿mi producto resuelve algo realmente difícil, riesgoso o costoso de mantener para el cliente, o solo resuelve algo que antes no valía la pena construir?
Las categorías que ofrecen red, escala, ecosistema, cumplimiento profundo, datos compartidos u operación global real seguirán teniendo mucho valor. Ninguna empresa sensata quiere reconstruir eso. McDermott tiene razón al pelear por ese terreno y probablemente lo gane.
Pero fíjate que, cuando dice “we are not in a SaaS neighborhood”, no está defendiendo el SaaS. Se está apartando. Está explicando por qué él sobrevive a algo que sí ocurrirá.
El problema es para todos los que no pueden decir esa frase. No necesitan esperar a que un agente les quite el cliente; basta con que el cliente haga las cuentas. Tendrán que dejar atrás la idea de que les compran porque el cliente no sabe hacerlo, y demostrar que ofrecen algo que sigue siendo difícil, costoso o poco inteligente de replicar internamente.
Quienes no lo entiendan descubrirán, quizá demasiado tarde, que la IA no solo les dio herramientas a ellos, sino también a sus clientes y a sus futuros competidores.
