La frase «SaaS is dead» ha estado de moda últimamente. El argumento es que, como estamos en una era en la que la IA puede escribir código, deberíamos dejar de pagar cuotas mensuales por SaaS y simplemente crear internamente lo que necesitamos.
En mi empresa, Emooove, hemos pasado los últimos meses totalmente comprometidos con la creación de nuestros sistemas internos. Al haberlo hecho de verdad, he experimentado tanto los éxitos como las lecciones dolorosas. Hoy quiero compartir mi perspectiva sobre la narrativa de «SaaS is dead» basándome en esa experiencia real.
Para ser claro, escribo esto desde la perspectiva de un usuario/constructor de sistemas, no de un proveedor de SaaS.
Una era increíble en la que cualquiera puede crear sistemas
Primero, como premisa: la llegada de Claude Code ha inaugurado de verdad una era en la que «cualquiera puede crear un sistema». No es una exageración.
En Emooove, una responsable de reclutamiento que solo llevaba dos meses con nosotros creó un ATS (Sistema de Seguimiento de Candidatos) interno. No es ingeniera y no tiene nada de experiencia en ingeniería. Aun así, creó un sistema funcional que se encarga de todo, desde importar candidatos hasta la gestión de selección y los paneles de control.
Además, ahora mismo estamos desarrollando un sistema interno para mejorar la eficiencia operativa y la calidad de nuestro negocio principal: los servicios de agencia de ventas. Me dedico a esto personalmente a diario y, a menos de dos semanas de haber empezado, siento que estamos a punto de crear algo bastante bueno.
Es comprensible que la gente quiera decir «SaaS is dead» cuando puedes crear internamente algo que, de otro modo, te costaría decenas o cientos de miles de yenes al mes en cuotas de SaaS.
Sin embargo, no todo es coser y cantar
Este es el punto principal. Cuando lo intentamos de verdad, no fue todo un camino de rosas.
1. El mantenimiento es increíblemente difícil
Para bien o para mal, puedes crear las cosas «sobre la marcha», así que toman forma rápidamente. Sin embargo, como los requisitos no están del todo definidos, hay muchas aristas sin pulir.
En el caso de nuestro ATS, nos encontramos con cosas como:
- Registros que debían importarse no se importaban.
- Los números del panel de control tenían errores por algún motivo.
- Faltaban botones críticos, lo que hacía que las operaciones se detuvieran en seco.
Nos topamos con muchas «omisiones que solo notamos después de empezar a usarlo». Con nuestro sistema interno de soporte de ventas hubo incluso una mañana en la que, de repente, no pudimos acceder a él y la pantalla no se abría.
Por supuesto, estos problemas se pueden arreglar en cierta medida definiendo los requisitos con más cuidado o haciendo mejoras sobre la marcha. Sin embargo, durante ese tiempo las operaciones normales del negocio se ven interrumpidas. Si empiezas a crear con la expectativa de que será «fácil y rápido», acabarás en un aprieto. Me di cuenta de que no deberías empezar con la mentalidad de «crear y terminar», sino con la de «crear y seguir arreglando».
Como nuestra escala de reclutamiento es pequeña, podemos arreglárnoslas aunque el ATS se detenga un rato. Pero me estremezco solo de pensar que fuera un sistema con muchas partes interesadas. A medida que aumentan el número de usuarios y el alcance del impacto, la pérdida por un solo fallo crece y el nivel de dificultad se dispara.
Aunque esto pueda tolerarse en sistemas internos, deberías ser extremadamente prudente a la hora de crear cualquier cosa destinada a la venta externa o que mire al mundo exterior, como un formulario de contacto.
2. La interfaz y la experiencia de usuario nunca llegan a pulirse
Me di cuenta de esto mientras creaba el sistema yo mismo: el acabado es bastante mediocre.
Las pantallas que la IA genera al principio tienen un aspecto «decente», pero cuando las usas de verdad, los detalles son torpes. Aunque con el tiempo puedes conseguir que tengan buen aspecto dándole instrucciones una y otra vez, eso requiere una obsesión y un tiempo considerables. Lo más probable es que la mayoría de la gente se conforme a mitad de camino.
Las interfaces de SaaS están pulidas porque diseñadores profesionales han pasado años incorporando los comentarios de los usuarios; eso no es algo que consigas gratis.
3. El problema de la seguridad
Esta es la parte más aterradora.
Incluso las personas sin formación de ingeniería pueden usar Claude Code para crear funciones y UI/UX con una actitud de «improvisar sobre la marcha». Pero, ¿es posible ponerse al día en seguridad de la misma manera? Al menos para mí, no lo es. Autenticación, gestión de permisos, respuesta ante vulnerabilidades: «que funcione» y «que sea seguro» son dos cosas completamente distintas.
En nuestro caso, afortunadamente contamos con alguien con experiencia como ingeniero de seguridad, así que nos aseguramos de que esa persona se encargue de esta parte. Aun así, siempre queda algo de inquietud. La idea de que una organización sin expertos suba información de clientes a un sistema construido a la ligera y lo haga público me hace sudar frío.
La lógica binaria de «vivir o morir» está equivocada
He enumerado los puntos negativos del desarrollo interno, pero, siendo honesto, también hay muchas cosas buenas.
- Puedes crear algo que se adapte perfectamente a tu negocio.
- Si quieres arreglar algo, puedes hacerlo al día siguiente.
- Casi no hay costos mensuales.
- La empresa adquiere know-how y la confianza de que «podemos crear sistemas nosotros mismos».
El problema está en querer reducirlo todo a «¿vivirá o morirá el SaaS?». Adoptar SaaS o crear internamente depende de la situación de cada empresa. Basándome en mi experiencia, estos son los cinco puntos que hay que tener en cuenta:
Punto 1: ¿Tienes ingenieros internos?
Si no los tienes, fracasarás en áreas como la seguridad, que las personas sin formación de ingeniería no pueden manejar a la ligera. Lo más aterrador es poder crear las funciones sin ser consciente de los peligros. El punto de inflexión está en si consigues que una persona con experiencia revise las áreas clave.
Punto 2: Número de partes interesadas
Si hay demasiadas, la pérdida cuando ocurre un fallo es enorme y el nivel de dificultad aumenta drásticamente. Por el contrario, las organizaciones pequeñas pueden experimentar con más facilidad porque, si algo se detiene, pueden simplemente disculparse. Es realista empezar por operaciones con un alcance de impacto reducido.
Punto 3: Sistemas externos vs. internos
Con los sistemas internos, el riesgo es limitado si algo sale mal. Sin embargo, en cualquier cosa externa, una sola fuga de información puede ser irreversible. Mientras que el SaaS te permite traspasar parte de la responsabilidad al proveedor, con el desarrollo interno todo es responsabilidad tuya. El valor de la «tranquilidad comprobada» del SaaS aumenta para cualquier cosa orientada al exterior.
Punto 4: ¿Puedes dedicar horas de trabajo al mantenimiento?
El mantenimiento es más frecuente de lo que imaginas. El desarrollo interno no es «crear y terminar», sino «seguir arreglando». ¿Puedes empezar con esa previsión? Si empiezas con una actitud a medias, acabarás enterrado corrigiendo fallos y eso pondrá presión sobre tu negocio principal.
Punto 5: ¿Te gusta o quieres hacer desarrollo con IA?
Al final, todo se reduce a esto. Es más tedioso y difícil de lo que pensarías, y es frustrante cuando la IA no te hace caso (risas). ¿Puedes llevarlo hasta el final pase lo que pase? Es una gran época para quienes lo disfrutan, pero no creo que sea algo que pueda sostenerse solo por sentido del deber.
Resumen: SaaS no está muerto. Solo hay más opciones.
Usé la palabra «fracasado» en el título, pero, siendo más precisos, fue «a punto de fracasar muchas veces». Continuamos con el desarrollo interno porque tenemos ingenieros con experiencia, nuestra organización todavía es pequeña, es principalmente para uso interno, estamos dispuestos a asumir el mantenimiento y, sobre todo, porque quiero hacerlo. Se podría decir que lo hacemos porque estamos en un entorno privilegiado en el que se cumplen los cinco puntos.
Por el contrario, si una empresa que no cumple estas condiciones se toma «SaaS is dead» al pie de la letra e intenta crear sus operaciones principales internamente, fracasará de verdad.
SaaS no está muerto. Lo que pasa es que ahora la opción de «crear» está abierta para todos. Evalúa con calma la situación de tu empresa y utiliza tanto el SaaS como el desarrollo interno. ¿No es esa la forma correcta de enfrentarse a esta era tan cómoda y, a la vez, tan precaria?
