Cuando la IA lo construye casi todo, ¿qué le queda al SaaS?

Cuando el código apenas cuesta, lo que protege a un SaaS ya no son las funciones sino los datos, la confianza y la distribución, y quien lance un producto nuevo puede gastar más dinero y tiempo en que lo encuentren que en construirlo.

El SaaS (software por el que se paga una suscripción y que se usa por internet) sigue existiendo. Pero ¿seguirá vendiéndose cuando la IA escriba casi todo el código? Es una pregunta que me hago a menudo últimamente. Este texto no es una noticia, es mi opinión.

Herramientas como Claude Code han acelerado de un modo casi anormal la velocidad a la que se construye software. Lo que antes llevaba semanas o meses ahora se hace en unos días. Si puedes explicar una idea de palabra, conectar unas cuantas API y tener un producto funcionando el lunes, nada impide que otra persona construya lo mismo.

Pensemos en un SaaS sencillo de 29 dólares (unos 26 euros) al mes. Si su función principal se puede rehacer con un buen prompt y unas horas de trabajo, ¿quién seguirá pagando?

Lo que avivó aún más esa inquietud fue REA, un proyecto de código abierto del que se habla mucho en GitHub.

REA (Reverse Engineer Anything) es una herramienta de código abierto con licencia MIT que conecta agentes de programación con IA como Claude Code, Codex y Cursor con herramientas de ingeniería inversa. La ingeniería inversa consiste en desmontar un programa sin código fuente para averiguar cómo funciona. El agente usa herramientas de análisis como Ghidra, Hopper e IDA (programas que hacen legible un archivo ejecutable) y explica, con pruebas, cómo se comporta un ejecutable o una aplicación. El resultado no es el código fuente original, sino pseudocódigo (una reescritura legible que parece código) y ensamblador (instrucciones cercanas a la máquina). Además, REA solo examina lo que está del lado del usuario: aplicaciones de escritorio o móviles, el código del front-end de los sitios web o el firmware. El código del servidor de un SaaS que solo funciona en la empresa queda fuera.

Algunos medios afirman que el proyecto superó las 100.000 estrellas en una semana, pero las cifras varían según la fuente y no he podido confirmar el número exacto. Algunos desarrolladores reaccionaron con «¿Ya se puede copiar una aplicación a partir de su binario?» y «Se acabó el foso del software (la barrera que mantiene lejos a la competencia)».

Lo que me llamó la atención no es el rendimiento de la herramienta sino el cambio de percepción. Antes, «programar es difícil» era la muralla. Luego «basta con construirlo» se tambaleó, y ahora se suma «se puede ver cómo se comporta sin el código fuente». La distancia entre una demo y un producto real sigue siendo grande. Aun así, si distribuyes algo en los dispositivos de los usuarios, como una aplicación de escritorio o móvil o una extensión del navegador, es difícil seguir dando por hecho que «mi lógica es secreta». El código que solo está en un servidor no se puede leer con esta herramienta, pero las pantallas y el comportamiento que se ven se copian tan fácilmente como siempre. El valor de saber construir y el de saber ocultar bajan los dos. Qué ocupará su lugar, todavía no lo sé.

¿Seguirá creciendo el SaaS existente?

Un SaaS bien asentado no desaparecerá de golpe. Sus clientes ya han puesto ahí sus datos y sus flujos de trabajo, y, dentro de una empresa, la frase «cambiemos a otra cosa» ya es un coste en sí misma. Las integraciones, los permisos, las auditorías y el soporte no los sustituye de un día para otro un clon (una copia rehecha) hecho en un fin de semana.

Lo que cambia es a qué se ata el crecimiento. Los productos que solo se distinguían por sus funciones sufrirán primero la presión de los precios. Las suscripciones por puesto, que cobran por cada persona usuaria, quizá tampoco funcionen tan bien cuando la automatización reduzca el número de puestos. En cambio, un producto que se hace cargo hasta el final del trabajo de un sector concreto puede volverse más sólido. Cuantos más datos se acumulan y más profundas son las integraciones, menos es la cuota mensual un dinero para comprar funciones y más un dinero para no tener que cargar uno mismo con el problema. Lo que REA ha sacudido es la idea de que «nadie ve el código, así que es seguro». No lo de que «nuestros datos están aquí y trabajamos cada día con esta pantalla».

Si se construye algo nuevo, ¿qué riesgos hay que asumir?

Que construir se haya abaratado significa que también se ha abaratado lanzarse con la misma idea. Veo cuatro riesgos.

Copia y precio.
Un producto hecho en un fin de semana lo puede rehacer otra persona en otro fin de semana. La fecha de caducidad de «yo lo hice primero» se ha acortado. Creo que 29 a 99 dólares (unos 26 a 88 euros) al mes siguen siendo posibles. Pero si la razón de ese precio es «programarlo es difícil» o «el código fuente es cerrado», me preocupa. En cuanto el cliente siente que podría construir algo parecido, la suscripción pasa a ser un lujo. Hay que convencer de que uno asume en su lugar el coste de construir, arreglar y proteger.

Mantenimiento.
Las demos son fáciles y la operación sigue siendo difícil. Caídas, seguridad, pagos, consultas de clientes y cambios de modelos o de API: aunque la IA escriba el código más rápido, no responde a «¿quién es responsable?». Si lo llevas tú solo, todo recae en una persona.

Elección de mercado.
Vender una función fina en un mercado amplio significa chocar enseguida con herramientas más grandes y copias más baratas. Profundizar en un problema estrecho da un mercado pequeño, exige conocer el sector y lleva tiempo ganarse la confianza. El deseo de ver ingresos pronto y el de elegir un lugar difícil de copiar suelen tirar en direcciones opuestas.

Distribución.
Cuanto más fácil es construir, más productos hay que nadie encuentra. Hoy, un producto construido pero invisible es casi como si no existiera. Sin un canal, hasta un producto terminado y bien hecho se queda en el almacén.

Los productos se multiplican: ¿subirá el coste del marketing?

Creo que sí, al menos si quieres comprar el mismo nivel de atención. La oferta de productos ha crecido, pero la atención de la gente, los resultados de búsqueda y el espacio en los feeds no han crecido al mismo ritmo. Cuando se amontonan páginas de aterrizaje (la primera página que presenta un producto) y «___ hecho con IA» parecidos, a los clientes les cuesta más elegir y a los vendedores más hacerse recordar.

Si el desarrollo se abarata, desarrolladores independientes que antes no podían pagar marketing pueden permitirse anuncios, pero también pujan más personas. El cuello de botella pasa del desarrollo al coste de adquisición de clientes (CAC, el dinero que cuesta traer a un cliente nuevo). En un producto de 29 dólares al mes, una pequeña subida del CAC alarga el tiempo hasta recuperar la inversión. Construir lleva un fin de semana; el marketing puede llevar meses.

Un sector estrecho, una red de clientes ya existente, el boca a boca y una experiencia que se mantiene visible en las búsquedas notan menos la subida del precio de los anuncios. Eso no significa que el marketing sea barato, sino que ya tienes distribución o la estás construyendo por tu cuenta.

¿Hay que caer bien a las empresas que tienen el tráfico?

Si el coste del marketing sube, la siguiente pregunta es si hay que hacer cola ante las plataformas que reúnen a la gente. Buscadores, tiendas de aplicaciones, redes sociales, marketplaces, tiendas de complementos de los grandes proveedores de SaaS y, en adelante, los lugares donde los asistentes de IA hacen recomendaciones: el tráfico se concentra ante unas pocas puertas. Para pasar, hay que ajustarse a sus reglas, comisiones y lógica de recomendación. «Caer bien» no es adulación, sino más bien preguntarse si tu producto encaja con los incentivos de esa empresa.

Tiene un precio. Si cambian las clasificaciones o las reglas de la API, o si la plataforma añade por su cuenta una función parecida, la visibilidad puede desaparecer de la noche a la mañana. Aun así, es difícil prescindir de ellas. Reunir suscriptores solo con distribución propia es una tarea mayor que el desarrollo. Por eso creo que si dejas el tráfico en manos de una sola puerta, esa puerta se convierte en tu negocio. Apoyarse en una plataforma conservando en tus manos parte de la relación con los clientes, de los datos y de las vías de salida es un compromiso. Entregar toda la visibilidad es alquilar.

¿Hace falta dinero para desarrollar?

Para el desarrollo en sí, la respuesta es más bien la contraria. Las herramientas de programación con IA, la nube, los pagos y las plantillas han bajado el listón para construir un producto y ponerlo en línea. En 2026, en la fase de prototipo, «hace falta capital para desarrollar» es cada vez menos cierto.

Lo que queda es otra clase de dinero: el que sirve para que te vean, para esperar y para aguantar caídas y clientes. Cuando sube el CAC, se suman las comisiones de las plataformas y empieza la guerra de precios, hace falta efectivo para resistir hasta tener beneficios. El uso del dinero pasa de comprar código a comprar tiempo. El bootstrapping (crecer con el dinero que uno mismo gana, sin inversores) no se ha vuelto imposible: el tramo que hay que superar se ha desplazado del desarrollo a la distribución y la supervivencia. Con mucho dinero se puede comprar ese tramo con publicidad y contrataciones. Con poco, hay que elegir antes una distribución más barata: un mercado estrecho, relaciones existentes o contenido.

Conclusión

Todavía no tengo una respuesta. Pero la dirección está algo más clara. El riesgo de quien construye algo nuevo es menos el fracaso técnico que acabar del lado de lo que es fácil de construir, fácil de copiar y fácil de enterrar. Lo que otros no alcanzan en un fin de semana es entender el problema del cliente, las integraciones y los datos, la confianza y la distribución. Esas cuatro cosas siempre estuvieron fuera del código. Por eso creo que un producto debe responder desde el principio a tres preguntas: «¿Por qué cuesta dar de baja esta suscripción?», «¿Cómo lo van a encontrar?» y «¿A quién no le alquilaré esa visibilidad?». Construir se ha abaratado, y lo que viene después se ha encarecido.

Qué podría cambiar para los desarrolladores

Lo que sigue es nuestra estimación y consejo, basados en el punto de vista personal de este texto.

• Revisa en qué se apoya tu precio. Comprueba si lo sostienen el almacenamiento de datos, las integraciones, la responsabilidad y la confianza, y no «programarlo es difícil» o «el código fuente es cerrado».
• Si distribuyes en los dispositivos de los usuarios, con una aplicación de escritorio o móvil o una extensión del navegador, parte de la base de que la lógica central puede leerse desde fuera y decide qué partes pasar a un servidor.
• Decide antes de construir dónde vas a encontrarte con tus clientes. No dejes toda tu visibilidad en una sola plataforma y conserva en tus manos parte de la lista de clientes y de los datos.
• Si el dinero escasea, elige primero una distribución que cueste poco en anuncios: un mercado estrecho, relaciones existentes o contenido.

Qué mirar a continuación

• Hasta qué punto se usan herramientas de ingeniería inversa como REA para copiar productos comerciales y qué normas ponen los fabricantes y las plataformas en respuesta.
• Si se hacen públicos los criterios con los que los asistentes de IA y las tiendas de aplicaciones recomiendan herramientas.

La conversión a euros sigue el tipo de cambio del 16 de octubre (1 dólar ≈ 0,89 euros) y está redondeada.

Fuentes

• REA: Reverse Engineer Anything (GitHub)