La primera lección de software que aprendí sin un computador
Mucho antes de trabajar con tecnología empresarial, aprendí una versión del problema build-versus-buy cuando era niño.
Crecí en una familia con recursos muy limitados. Teníamos lo necesario, pero no había mucho espacio para cosas no esenciales. Un día, un primo cuya familia podía permitirse más cosas me invitó a su casa a jugar Monopoly. Para mí fue un shock. El juego se sentía sofisticado, estratégico, casi como un pequeño sistema operativo para dinero, propiedad, negociación y azar.
Cuando volví a casa, pregunté a mis padres si podíamos comprar uno. Me dijeron, con cariño, que era demasiado caro.
Así que construí el mío.
Con papel, pegamento, piezas improvisadas y mucha imaginación, creé una versión artesanal de Monopoly. Pero no solo lo copié. Lo cambié. Añadí reglas. Adapté el tablero. Lo hice nuestro. Mi hermano menor y yo jugamos durante horas, y él todavía recuerda lo mucho que nos divertimos con aquel Monopoly hecho a mano.
No lo sabía en ese momento, pero esa experiencia me enseñó algo que hoy se está volviendo central para el software empresarial: cuando el acceso está limitado, las personas buscan formas de construir. Y cuando las herramientas para construir se vuelven radicalmente más baratas, la frontera entre comprar y crear empieza a moverse.
Eso es lo que la IA está haciendo ahora con el software. No está reduciendo la ambición. Está haciendo la ejecución más accesible. La inteligencia se está volviendo más abundante, y la escala de lo que una persona o un equipo pequeño puede crear se está expandiendo de forma dramática.
Esta es la razón personal por la que la pregunta sobre la “muerte del SaaS” me importa. La historia no trata realmente de que el SaaS desaparezca. Trata de lo que ocurre cuando la capacidad deja de estar bloqueada detrás de accesos caros y empieza a convertirse en algo que más personas pueden moldear por sí mismas.
Por qué importa ahora
A escala empresarial, el mismo patrón ha definido el software durante dos décadas. Si el negocio necesitaba una capacidad, compraba una suscripción. Construir internamente era lento, caro, arriesgado y políticamente difícil. SaaS ganó porque convirtió el software en gasto operativo e hizo que la capacidad pareciera disponible de inmediato.
Esa lógica está siendo repriced.
El argumento no es que todo SaaS desaparece. Eso sería intelectualmente flojo. Los sistemas de registro, plataformas reguladas, redes de colaboración profundas e infraestructura de alta confianza seguirán existiendo. El argumento más estrecho e importante es que el gatekeeping basado en licencias está perdiendo su privilegio económico. Cobrar por asiento por capacidad genérica es cada vez más difícil de defender cuando la mitad de los asientos no se usa, los proveedores siguen subiendo precios y equipos asistidos por IA pueden reproducir workflows internos concretos en días.
El ensayo completo adjunto desarrolla el caso entero. Este artículo es la versión ejecutiva: qué cambió, dónde cae la presión, dónde sobrevive el SaaS y qué deberían hacer los líderes antes del siguiente ciclo de renovaciones.
El problema de desperdicio SaaS
El primer problema no es la IA. Es el desperdicio.
El SaaS Management Index 2025 de Zylo registra un gasto anual promedio de $4,830 por empleado, un aumento de 21,9% tras varios años de contención. Productiv estima que aproximadamente 53% de las licencias SaaS provisionadas están sin uso o infrautilizadas. Benchmarks anteriores de Zylo situaban el desperdicio promedio anual de licencias en aproximadamente $18 millones por empresa, mientras el portfolio empresarial promedio contiene alrededor de 275 aplicaciones SaaS.
Esto no describe un mercado sano operando en el margen. Describe un mercado donde los compradores tienen dificultad para ver lo que poseen, los vendedores pueden empaquetar y repricing, y el hábito de renovación hace más trabajo que el caso de negocio.
SaaS fue racional cuando comprar era más barato que construir. Pero una suscripción no es intrínsecamente eficiente. Es eficiente solo cuando la capacidad rentada es más barata, segura, rápida y mejor que la alternativa. La IA cambia la alternativa.
La economía de construir se ha invertido
El argumento clásico de build-versus-buy asumía que la capacidad de ingeniería era escasa. Un año completo de un ingeniero podía costar cientos de miles de dólares. Una herramienta SaaS repartía el desarrollo de producto entre miles de clientes. La aritmética favorecía comprar.
El desarrollo asistido por IA rompe esa aritmética en categorías específicas.
La evidencia más fuerte no es el hype sobre coding assistants. Es la evidencia de comportamiento de empresas y operadores. La encuesta build-versus-buy de Retool en 2026 reportó que 35% de las empresas ya habían reemplazado al menos una herramienta SaaS con un equivalente construido a medida, mientras 78% esperaba construir más herramientas internas en el año siguiente. Las categorías más expuestas fueron exactamente las esperadas: automatizaciones de workflow, sistemas administrativos internos, dashboards, extensiones básicas de CRM, ticketing y formularios.
Esto también se ve en mi propio portfolio. El Dashboard de Benchmarking de Modelos de IA era el tipo de herramienta interna de decisión que un equipo tradicional estimó en siete meses y más de $50,000. Fue construido en horas con desarrollo asistido por IA. Eso no significa que todo sistema empresarial deba construirse así. Significa que la respuesta por defecto cambió para herramientas internas con requisitos claros y riesgo acotado.
La pregunta ya no es: ¿podemos construir esto? La pregunta es: ¿esto es tan genérico que seguir rentándolo es la opción cara?
De SaaS a Intelligence-as-a-Service
El cambio más profundo no es build versus buy. Es la unidad de valor.
SaaS monetizó acceso. Un asiento daba permiso a una persona para usar software. Intelligence-as-a-Service monetiza trabajo completado: un caso de cliente resuelto, un workflow generado, un claim procesado, una cuenta conciliada, un lead cualificado, una decisión entregada.
Ese cambio ya es visible. Sierra cobra agentes de atención al cliente por caso resuelto. Intercom cobra Fin por resolución. Microsoft Copilot Studio usa consumo basado en acciones. Salesforce ha experimentado con conversaciones, flex credits, licencias Agentforce por usuario y ahora agentic work units. Anthropic y OpenAI cobran alrededor de uso, no asientos humanos.
La observación de Aaron Levie es la versión más limpia: si las empresas eventualmente tienen cien o mil veces más agentes que personas, el pricing por asiento deja de ser coherente. Los usuarios no humanos no mapean bien a licencias humanas. La superficie de monetización pasa a ser la acción.
Por eso el Dashboard de Inteligencia Operacional Helion importa como prueba. El valor no es un dashboard que alguien lee. El valor es una capa operacional AI-native que observa el negocio, interpreta señales e informa a líderes en lenguaje natural. Eso no es software-como-acceso. Es inteligencia entregada como trabajo.
El mismo patrón aparece en Pipesignal. El sistema no solo proporciona un lugar para almacenar datos comerciales. Los agentes descubren proyectos, enriquecen señales, priorizan cuentas y acercan a humanos a conversaciones de revenue. La interfaz se vuelve secundaria. El workflow ejecutado se convierte en el producto.
La señal del SaaSpocalypse
Los mercados públicos empezaron a notar la misma presión estructural a comienzos de 2026. El iShares Expanded Tech-Software ETF cayó con fuerza en febrero y marzo, mientras varias compañías de software empresarial cotizadas sufrieron caídas más profundas. Los analistas llamaron al episodio SaaSpocalypse.
Esto no es un argumento de market timing. No es asesoramiento de inversión. La señal estratégica es más simple: los inversores empezaron a cuestionar la durabilidad de márgenes de software construidos sobre expansión de asientos, switching costs y diferenciación de producto que la IA puede comprimir.
Un proveedor SaaS todavía puede ser un gran negocio. Pero el mercado está separando software con moats reales de software que era caro principalmente porque construir solía ser difícil.
Dónde sobrevive el SaaS
La contra-tesis importa. La muerte del SaaS no es literal. La muerte es selectiva.
SaaS sobrevive cuando el moat no es solo la interfaz. Salesforce sigue profundamente insertado como sistema de registro para muchas organizaciones comerciales. Figma se beneficia de redes de colaboración. Stripe y Shopify están defendidos por confianza, distribución, escala de merchants y gravedad de ecosistema. Los sistemas regulados sobreviven porque assurance, compliance, auditabilidad y resiliencia operacional importan más que paridad funcional.
El producto expuesto es distinto: una herramienta de workflow con usuarios contables, lógica genérica, pocos efectos de red, baja carga de compliance y funcionalidad que puede describirse con precisión. Si un operador puede especificarla claramente, si los datos son internos, si el proceso está acotado y si el riesgo es manejable, la opción de construir vuelve a la mesa.
Eso no hace que construir internamente sea gratis. El código generado o asistido por IA todavía trae riesgo de seguridad, deuda arquitectónica, dependencias inventadas, brechas de gobernanza y obligaciones de mantenimiento. La respuesta correcta no es construir todo. La respuesta correcta es clasificar el estate inteligentemente.
La respuesta ejecutiva: rentar, reemplazar, envolver, defender
La respuesta práctica es una disciplina de portfolio.
Cada renovación SaaS debería clasificarse en cuatro buckets:
- Rentar. Siga pagando donde el producto es eficiente, diferenciado y no vale estratégicamente reconstruir.
- Reemplazar. Reconstruya workflows internos estrechos donde el desarrollo asistido por IA crea una ventaja clara de costo, velocidad o fit.
- Envolver con agentes. Mantenga el sistema de registro, pero mueva la experiencia de usuario y la capa de ejecución hacia workflows agénticos.
- Defender. Proteja plataformas con moats reales, datos regulados, integraciones profundas o alto riesgo operacional.
Aquí las herramientas del sitio conectan directamente con la investigación. Use el Marco Build vs. Buy vs. Partner para evaluar estrategia de adquisición, la Calculadora de ROI de IA Agéntica para modelar el caso financiero, y la Matriz de Priorización de Casos de Uso para decidir qué workflows merecen atención primero.
La peor respuesta es ideológica. “Siempre comprar” está obsoleto. “Siempre construir” es imprudente. La respuesta disciplinada es tratar la capacidad de software como un portfolio vivo.
Qué significa esto para CIOs y CFOs
Para CIOs, esto es un desafío de gobernanza. El shadow building ocurrirá con o sin aprobación de IT. La postura más segura es crear reglas, patrones aprobados, revisión de seguridad, componentes reutilizables y umbrales claros para cuándo los builds internos son aceptables.
Para CFOs, esto es un desafío de asignación de capital. Las renovaciones SaaS ya no deberían aprobarse porque la renovación del año pasado se aprobó. Utilización de licencias, criticidad del workflow, costo de reemplazo, lock-in de proveedor y medición de outcomes pertenecen a la misma conversación.
Para líderes de negocio, esto es un desafío de imaginación. Cuando el costo de producir software cae, el recurso escaso pasa a ser juicio: qué debería existir, qué no, y dónde la organización tiene suficiente gusto y contexto para construir algo mejor que el promedio genérico de un proveedor.
La economía de licencias recompensaba acceso. La siguiente economía recompensa articulación, distribución, datos y juicio.
Fuente y divulgación
Este artículo se basa en mi ensayo completo, *The Death of Software-as-a-Service*. El PDF completo está disponible para descarga abajo. Incluye el argumento completo, figuras, fuentes, contra-tesis y referencias.
Esto no es asesoramiento de inversión, legal, financiero, procurement o seguridad. La tesis es estratégica: el SaaS no desaparece, pero el default económico que hacía inevitable el pricing por asiento se está rompiendo.