¿De verdad la IA permite que cualquiera cree un SaaS?

Desde que aparecieron Cursor, Lovable o Bolt, se oye siempre la misma frase: «la IA permite ahora que cualquiera cree un SaaS». Es en parte verdad, y en parte por eso resulta peligrosa.

Verdad, porque hoy se puede construir en unas horas lo que antes llevaba semanas. Un emprendedor puede sacar un prototipo, automatizar un trozo de proceso o montar una pequeña app sin equipo técnico. Es un cambio real, y nosotros mismos lo usamos cada día.

Engañosa, porque depende muchísimo de lo que entendamos por «un SaaS». Y no todo el mundo habla de lo mismo.

No todas las aplicaciones son iguales

A menudo metemos en el mismo saco tres cosas muy distintas: la herramienta personal que te apañas para ti, el MVP que sacas para probar una idea, y la aplicación de producción que funciona cada día con clientes reales.

Para las dos primeras, la IA lo ha cambiado todo. Describes lo que necesitas en lenguaje natural, generas una interfaz, una base de datos, un par de automatizaciones, y esa misma tarde tienes algo que funciona. Para validar una idea o resolver un problema puntual, es una pequeña revolución.

Una aplicación que usan cada día tus clientes o tus equipos es otra historia. Y ahí es donde la frase del principio se vuelve tramposa.

Una app de producción no se reduce al código

En cuanto una aplicación pasa a producción, el código es solo la parte visible. Detrás hay que sostener usuarios reales, datos a veces sensibles, roles y permisos, pagos, integraciones con otros sistemas, restricciones regulatorias, la seguridad, las actualizaciones, las pruebas, la monitorización, la disponibilidad del servicio. Y todo eso tiene que seguir aguantando cuando la empresa crece.

Mientras nadie la usa, un bug es una línea que corregir. En producción, ese mismo bug se convierte en ingresos perdidos, una actividad parada, un cliente descontento o una brecha de seguridad. El decorado cambia por completo.

Un ejemplo de nuestro propio trabajo. Una startup del sector salud nos contacta para gestionar sus pacientes, sus profesionales, sus citas y sus pagos. El reflejo fácil habría sido generar la app de inmediato. Solo que el verdadero reto no era el código: había que cumplir las exigencias de confidencialidad del ámbito médico (conformidad con HIPAA en Estados Unidos) y, a la vez, que fuera usable por equipos que no son ingenieros. Fueron esas restricciones, y no la velocidad de generación, las que marcaron las decisiones que de verdad importan.

El verdadero tema no es la calidad del código

La mayoría de los debates sobre la IA giran en torno a una pregunta: «¿es bueno el código generado?». En realidad, no es el problema principal. Ni el mejor código hace una buena aplicación.

Los proyectos que aguantan se apoyan antes en otra cosa: una arquitectura adecuada, un buen modelado de datos, una gestión rigurosa de los permisos, una estrategia de seguridad coherente, pruebas automatizadas, una comprensión real de las necesidades del negocio. La IA acelera enormemente la ejecución de todo eso. No sustituye la comprensión global del sistema.

Lo vimos con una fundación cuyas herramientas, apañadas a lo largo de los años, se habían vuelto inmanejables. El reflejo habría sido regenerarlo todo. El verdadero problema era más profundo: su modelo de datos ya no se parecía a su forma de trabajar. Ninguna IA iba a adivinar eso por ellos. Hubo que volver a poner los cimientos en su sitio antes de tocar lo demás.

Lo que de verdad está cambiando

Durante mucho tiempo, saber escribir código fue EL factor diferenciador para crear software. Hoy, el código se está convirtiendo poco a poco en una commodity. El valor se desplaza a otro sitio: al diseño del sistema, a la comprensión de los procesos de negocio, a las decisiones de arquitectura, a la calidad de los datos, y a la capacidad de formular los problemas correctos antes de poner en marcha la máquina.

Así que la pregunta ya no es solo «¿quién sabe programar?», sino «¿quién entiende de verdad el sistema que construye?». Es un desplazamiento discreto, pero lo cambia todo.

Nuevos perfiles híbridos

También por eso las fronteras entre ciertos oficios se vuelven más difusas. Vemos surgir perfiles que combinan varias gorras: product managers muy técnicos, product engineers, diseñadores que programan, CTO orientados a producto.

Lo que los distingue no es tanto el dominio de las herramientas como su capacidad de conectar tres cosas: los retos de negocio, las restricciones técnicas y las necesidades de los usuarios. Es exactamente lo que llamamos Product Thinking, y es justo lo que la IA no sabe hacer por ti.

Lo que significa para una pyme

Para una empresa, la cuestión no es usar la IA para producir más rápido. Es construir los sistemas adecuados. La IA hace caer los costes y los plazos de creación de herramientas digitales, y es una oportunidad real para las pymes que quieren digitalizar sus operaciones o lanzar nuevos servicios.

Pero el éxito de un proyecto sigue dependiendo de lo mismo de siempre: entender la necesidad real, diseñar una solución adecuada, estructurar bien los datos, asegurar los procesos y pensar en la escalabilidad desde el principio. Nada nuevo, y de eso se trata precisamente.

La IA transforma la manera de construir aplicaciones. No elimina la necesidad de experiencia, la desplaza hacia quienes saben combinar visión de producto, comprensión del negocio, arquitectura y ejecución. Ahí es, probablemente, donde se juega hoy la verdadera ventaja, para quienes sepan aprovecharla.

Sobre el autor

Julien Andrieu. 20 años de experiencia en Product Management y desarrollo de productos digitales. Tras pasar por startups, editores de SaaS y grupos internacionales, hoy acompaña a las pymes en el diseño de soluciones digitales centradas en las necesidades del negocio.

¿Te apetece que hablemos? Escríbenos: hello@capamoon.com. O si estás en Barcelona, escríbenos para tomar un café ☕ Un abrazo.