La frase "SaaS está muerto" ha estado en tendencia ú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 construir lo que necesitamos internamente.
En mi empresa, Emooove, hemos pasado los últimos meses totalmente dedicados a construir nuestros sistemas internos. Al haberlo hecho realmente, he experimentado tanto los éxitos como las dolorosas lecciones. Hoy quiero compartir mi perspectiva sobre la narrativa de "SaaS está muerto" a partir de 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 construir sistemas
Primero, como premisa: la llegada de Claude Code realmente ha dado lugar a una era en la que "cualquiera puede construir un sistema". No es una exageración.
En Emooove, una líder de reclutamiento que solo llevaba dos meses con nosotros construyó un ATS (Sistema de Seguimiento de Candidatos) interno. No es ingeniera y tiene cero experiencia en ingeniería. A pesar de eso, creó un sistema funcional que maneja todo, desde la importación de candidatos hasta la gestión de selección y los dashboards.
Además, actualmente estamos desarrollando un sistema interno para mejorar la eficiencia operativa y la calidad de nuestro negocio principal: los servicios de agencia de ventas. Personalmente, me dedico a esto todos los días, 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 está muerto" cuando puedes construir internamente algo que, de otro modo, costaría decenas o cientos de miles de yenes al mes en cuotas de SaaS.
Sin embargo, no todo es un camino de rosas
Este es el punto principal. Cuando realmente lo intentamos, no fue todo color de rosa.
1. El mantenimiento es increíblemente difícil
Para bien o para mal, puedes construir cosas "sobre la marcha", así que toman forma rápidamente. Sin embargo, como los requisitos no están del todo definidos, hay muchos cabos sueltos.
En el caso de nuestro ATS, vimos cosas como:
- Registros que se suponía que debían importarse no se importaban.
- Los números del dashboard tenían errores por alguna razón.
- Faltaban botones críticos, lo que detenía las operaciones por completo.
Nos encontramos con muchas "omisiones que solo notamos después de empezar a usarlo". Con nuestro sistema interno de soporte de ventas, incluso hubo una mañana en la que, de repente, no pudimos acceder y la pantalla no cargaba.
Por supuesto, estos problemas se pueden solucionar hasta cierto punto 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 construir con la expectativa de que será "fácil y rápido", terminarás en un aprieto. Me di cuenta de que no debes empezar con la mentalidad de "construir y terminar", sino de "construir y seguir arreglando".
Como nuestra escala de reclutamiento es pequeña, podemos arreglárnoslas aunque el ATS se detenga un rato. Pero me estremezco al pensar si esto 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 ser tolerable para sistemas internos, deberías ser extremadamente cauteloso a la hora de construir cualquier cosa para la venta externa o cualquier cosa que mire hacia el exterior, como un formulario de contacto.
2. El UI/UX nunca llega a pulirse
Me di cuenta de esto mientras construía el sistema yo mismo: el acabado es algo mediocre. Las pantallas que la IA genera inicialmente se ven "decentes", pero cuando realmente las usas, los detalles son toscos. Aunque con el tiempo puedes lograr que se vean bien dando instrucciones una y otra vez, eso requiere una obsesión intensa y tiempo. La mayoría de las personas probablemente terminará conformándose 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 obtengas gratis.
3. El problema de la seguridad
Esta es la parte más aterradora.
Incluso los no ingenieros pueden usar Claude Code para construir funciones y UI/UX con una actitud de "improvisar y ya". 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 diferentes.
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í, queda un poco de ansiedad. La idea de que una organización sin expertos ponga información de clientes en un sistema construido por capricho 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, honestamente, también hay muchas cosas buenas.
- Puedes construir algo que se ajuste perfectamente a tu negocio.
- Si quieres arreglar algo, puedes hacerlo al día siguiente.
- Casi no hay costos mensuales.
- La empresa gana know-how y la confianza de que "podemos construir sistemas nosotros mismos".
El problema está en tratar de simplificarlo a "¿SaaS vivirá o morirá?". Adoptar SaaS o construir internamente depende de la situación de cada empresa. Con base en mi experiencia, estos son los cinco puntos a considerar:
Punto 1: ¿Tienes ingenieros internos?
Si no los tienes, fallarás en áreas como la seguridad, que los no ingenieros no pueden manejar a la ligera. Lo más aterrador es poder construir las funciones sin darte cuenta de los peligros. El punto de inflexión es si puedes conseguir a una persona con experiencia para que 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 más fácilmente porque pueden disculparse si las cosas se detienen. Es realista empezar con operaciones que tengan un alcance de impacto pequeño.
Punto 3: Sistemas externos vs. internos
Con los sistemas internos, el riesgo es limitado si algo sale mal. Sin embargo, para cualquier cosa externa, una sola filtración de información puede ser irreversible. Mientras que SaaS te permite delegar parte de la responsabilidad al proveedor, con el desarrollo interno todo es tu responsabilidad. El valor de la "tranquilidad comprobada" de SaaS crece para todo lo que mira hacia el exterior.
Punto 4: ¿Puedes destinar horas-hombre al mantenimiento?
El mantenimiento ocurre más de lo que imaginas. El desarrollo interno no es "construir y terminar", sino "seguir arreglando". ¿Puedes empezar con esa previsión? Si empiezas con una actitud a medias, terminarás enterrado arreglando fallas y eso presionará tu negocio principal.
Punto 5: ¿Te gusta/quieres hacer desarrollo con IA?
Al final, todo se reduce a esto. Es más tedioso y difícil de lo que piensas, y es frustrante cuando la IA no te hace caso (risas). ¿Puedes llevarlo hasta el final de todos modos? Es una gran era para quienes lo disfrutan, pero no creo que sea algo que se pueda sostener solo con 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 exactos, fue "casi fracasamos muchas veces". Seguimos con el desarrollo interno porque tenemos ingenieros con experiencia, nuestra organización todavía es pequeña, es principalmente para uso interno, estamos preparados para comprometernos con el mantenimiento y, sobre todo, porque quiero hacerlo. Podrías 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 está muerto" al pie de la letra e intenta construir sus operaciones principales internamente, fracasará de verdad.
SaaS no está muerto. Solo que la opción de "construir" ahora está abierta para todos. Evalúa con calma la situación de tu empresa y usa tanto SaaS como el desarrollo interno. ¿No es esa la forma correcta de lidiar con esta era tan conveniente y, a la vez, precaria?
