Vibe coding: por qué construir un SaaS con IA no es tener un producto.

Hacer un SaaS con IA en un fin de semana no es tener un producto. Es tener una captura de pantalla bonita.

Y sin embargo, LinkedIn lleva doce meses llenándose de gente que acaba de "lanzar" su SaaS con Lovable, con Bolt, con Cursor, con V0. Lanzar entre comillas. Porque lanzar, lo que se dice lanzar, nadie ha lanzado nada.

Han montado un prototipo. Le han puesto un dominio. Han publicado tres screenshots. Y han llamado a eso producto.

El vibe coding es real. Las herramientas son reales. La productividad que habilitan es real. Lo que no es real es la idea, cada vez más extendida, de que entre hacer una demo y tener un negocio hay un fin de semana de distancia. Esa distancia sigue siendo, como siempre ha sido, de veinte mil horas.

Qué es el vibe coding (y por qué todo el mundo lo hace ahora)

El término lo popularizó Andrej Karpathy en 2024. "Fully give in to the vibes", escribió. Describir lo que quieres en lenguaje natural, aceptar el código que la IA te devuelve, iterar por intuición. No revisar el código a fondo. No pararse en la arquitectura. Fluir.

Dos años después, el concepto se ha comido el mundo. Cualquiera con una cuenta de Cursor, Replit, Lovable, Bolt o v0 puede levantar una aplicación funcional en horas. Frontend, backend, base de datos, autenticación. Todo generado, todo deploy en un clic. La barrera de entrada al desarrollo de software ha caído a cero.

Ese es el hecho. Y es un hecho bueno. El problema no es la herramienta. El problema es la conclusión que mucha gente ha sacado de ella.

La conclusión errónea: si ahora puedo construir cualquier cosa, ya tengo un negocio.

La conclusión correcta: si ahora cualquiera puede construir cualquier cosa, el único diferencial que queda es todo lo que ocurre fuera del código.

La diferencia entre una demo y un producto

No es sutil. No es semántica. Es la diferencia entre lo que funciona en tu portátil y lo que sobrevive a un lunes por la mañana.

Una demo impresiona al que la ve. Un producto resuelve un problema al que paga. Son cosas muy distintas.

• Una demo se rompe con tres usuarios a la vez. Un producto aguanta picos de tráfico, caídas de proveedores externos, bugs que aparecen solo en producción. Si nunca has escrito un deploy rollback a las 3 de la madrugada, no tienes un producto.
• Una demo tiene seguidores. Un producto tiene clientes. Los seguidores aplauden tu tweet y siguen con su vida. Los clientes te escriben enfadados cuando algo no funciona y deciden si renuevan en función de si les respondes.
• Una demo resuelve un problema que te has inventado. Un producto resuelve un problema que existía antes de que tú llegaras. Uno lo sabes porque veinte personas te lo dijeron sin pedírselo tú. El otro lo sabes porque "a ti te encantaría una herramienta que…".
• Una demo se construye en un fin de semana. Un producto tarda dieciocho meses en tener los diez primeros clientes que pagan y renuevan. Si quieres saber si tienes un negocio, espera a que alguien te pague dos veces. El primer pago puede ser curiosidad. El segundo ya no.

Qué ha democratizado la IA de verdad

Vamos a ser justos. La IA ha cambiado algunas cosas que antes eran barreras reales.

Construir. Lo que hace tres años requería un desarrollador senior y dos meses, hoy lo haces tú mismo en una tarde. Es verdad. Eso es bueno.

Prototipar. Validar una idea con una maqueta funcional cuesta lo mismo que un café. Eso es bueno también.

Iterar. Cambiar de rumbo ya no supone tirar tres semanas de desarrollo a la basura. Eso es muy bueno.

Hasta ahí, todo correcto.

Lo que no ha democratizado la IA, por si alguien se había confundido:

• Conocer a tu cliente.
• Venderle algo.
• Cobrarle recurrentemente.
• Retenerlo.
• Montar un canal de adquisición que no dependa de ti publicando en LinkedIn.
• Aguantar seis meses sin ingresos.
• Responder un email de queja un domingo por la tarde.
• Saber por qué tu NPS bajó tres puntos este mes.
• Decir "no" a funcionalidades que te pide un cliente grande porque descentrarían el producto.
• Pagar tus impuestos.

Todas esas cosas siguen costando el mismo trabajo que hace veinte años. Y son, en aproximadamente el 90% del resultado final, lo que separa un negocio de un hobby.

La IA ha democratizado la parte del iceberg que se ve. Sigue sin tocar la parte del iceberg que te hunde el barco.

Los siete trabajos invisibles que convierten una demo en producto

Lo que no se ve en los tweets de "he montado un SaaS en 48 horas" es todo esto. Hágase la prueba: pregunte a cualquiera que esté enseñando su "producto" reciente cuál de estos siete trabajos tiene hechos.

1. Conversaciones con clientes reales antes de escribir código. No encuestas. No "he preguntado en Twitter". Veinte llamadas de 45 minutos con personas que encajan con tu perfil de cliente objetivo. Si no sabes articular qué duele exactamente a tu ICP, estás construyendo en el vacío. Y en el vacío el mejor código del mundo no vale nada.

2. Modelo de negocio cerrado en una página. Quién paga, cuánto paga, cuántos necesitas, cómo los captas, cuánto te cuesta captarlos, cuánto tiempo se quedan. Si no cabe en una página es porque aún no está claro. Lo no claro no se vende.

3. Infraestructura operativa. Monitorización, alertas, logs, rollback, copias, seguridad, RGPD, términos de servicio, política de privacidad, registro mercantil, alta de autónomos o sociedad, facturación recurrente, contabilidad, pasarela de pago que no se rompe los viernes. Esto no lo escribe Cursor por ti.

4. Soporte. Alguien tiene que responder el email de un usuario a las 22:47 de un sábado porque no puede loguearse. Ese alguien eres tú los primeros dos años. Si no puedes o no quieres, no montes un SaaS. Monta un curso.

5. Un canal de adquisición. No "voy a hacer Growth" ni "me voy a volcar en LinkedIn". Un canal probado: SEO, ads, partners, referral, outbound. Uno. Con CAC calculado, con ratio CAC:LTV sano, con una hipótesis de escala que no dependa de tu energía personal. Un negocio que solo funciona si tú publicas todos los días no es un negocio, es una rueda de hámster con logo.

6. Retención medida. Churn mensual por debajo del 5% en B2C, por debajo del 2% en B2B, con cohortes y payback periods reales. El churn del primer mes es contener la respiración. El churn del mes seis es lo que define si tienes producto o si tienes curiosidad monetizada.

7. Un foso defensivo. Distribución propia, marca, datos, red de nodos, especialización vertical, coste de cambio. Algo que no pueda copiar mañana el siguiente con la misma cuenta de Cursor. Sin foso, cualquiera que te vea replica tu SaaS en el fin de semana siguiente al tuyo. Y entonces empieza la guerra de precios. Y las guerras de precios se pierden todas.

Qué separa a los que sobreviven al hype

Cada ciclo tecnológico deja un 1% de supervivientes y un 99% de cementerio. Las punto-com, las apps móviles, las extensiones de Chrome, los bots de Telegram, los NFTs, los cursos online. Y ahora el vibe coding.

En los cinco anteriores, los supervivientes compartieron tres cosas. En el del vibe coding va a pasar exactamente lo mismo.

Obsesión por un segmento concreto. Los supervivientes venden a alguien muy específico. Los que mueren venden a "emprendedores" o a "pymes" o a "creators". Vender a todos es vender a nadie.

Profundidad, no amplitud. Mientras los del hype añaden funcionalidades cada semana para justificar tweets, los supervivientes hacen una sola cosa bien durante tres años. Nadie recuerda al SaaS que hacía quince cosas. Todos recuerdan al que hacía una.

Distribución antes que producto. El que lleva dos años escribiendo en LinkedIn sobre el problema que su producto resuelve, cuando lanza su SaaS ya tiene mil clientes esperando. El que llega con el SaaS construido en una semana descubre, al día siguiente del lanzamiento, que no conoce a nadie al que contárselo.

Si estás construyendo un SaaS con IA ahora mismo y no tienes una de esas tres cosas, tienes un problema. Y el problema no es la IA. Es que estás saltándote las mismas fases que la gente se ha saltado en todos los hypes anteriores. Terminaron igual.

Cuándo sí tiene sentido usar vibe coding

No seamos tontos. El vibe coding tiene su sitio. Tiene varios sitios, de hecho.

Tiene sentido para prototipar rápido y enseñar una idea a un cliente potencial antes de hablar de presupuesto. Tres horas contra tres semanas. Todo ganancia.

Tiene sentido para resolver problemas internos de tu propia empresa. Automatizaciones, herramientas de reporting, microapps para uso interno. Nadie te va a pedir SLAs ni RGPD porque nadie externo lo va a usar.

Tiene sentido para aprender a programar en 2026. Leyendo el código que te genera la IA y corrigiéndolo se aprende mucho más rápido que con un curso.

Tiene sentido para proyectos personales sin aspiración comercial. Si quieres hacer una app para organizar las recetas de tu abuela, hazla. Disfruta. No le pongas dominio ni pricing.

Lo que no tiene sentido es confundir ninguna de esas cuatro cosas con un negocio.

Qué hacer si ya has caído en la trampa

Supongamos que has dedicado los últimos tres meses a montar un SaaS con vibe coding. Dominio comprado. Logo en Figma. Página de aterrizaje con tres CTAs. Y diez clientes que son, al examinarlos de cerca, tus amigos y dos primos.

Antes de tirar todo a la basura, tres preguntas.

Primero. ¿Has hablado con veinte clientes reales que no te conozcan de antes? Si la respuesta es no, para de construir. Haz esas veinte llamadas. Si después de las veinte tu idea sigue en pie, es que tienes algo. Si no, lo has descubierto barato.

Segundo. ¿Alguien te ha pagado dos veces? No uno. Dos. Si la respuesta es no, tu producto no ha tocado la realidad todavía. No es producto. Es intento.

Tercero. ¿Puedes explicar en una frase a quién ayudas, en qué problema, de qué forma única y cuánto cuesta? Si necesitas un PDF de cuarenta páginas para explicarlo, es que aún no está claro. Y lo no claro no se vende.

Si las tres respuestas son sí, tienes un producto en fase temprana. Sigue. Iterar es tu trabajo ahora.

Si alguna respuesta es no, lo que tienes es una demo. Y tratar una demo como si fuera un producto es la forma más rápida de perder dos años de tu vida. Mejor dos meses de humildad ahora.

La ventaja real en la era del vibe coding

Si construir ya no es barrera, ¿dónde está la ventaja?

Donde siempre ha estado. En todo lo que un modelo no puede automatizar todavía: conocer a tu cliente mejor que él mismo, contar lo que haces con una claridad que duela, aguantar el aburrimiento de hacer lo mismo bien durante tres años, tener criterio para decir que no a lo obvio, distribuir con coherencia.

Nada de eso lo hace Cursor por ti. Ni Lovable. Ni v0. Ni Bolt.

Lo cual es, si lo piensas con calma, una noticia excelente. Porque significa que el único diferencial que queda es completamente humano. Y, a diferencia del código, no es imitable en un fin de semana.

La IA no ha matado el trabajo duro. Solo ha movido el trabajo duro a otra parte. La parte que sigue doliendo. La parte por la que la gente pagaba antes y va a seguir pagando después.

Si tu plan para 2026 es vibe-codear un SaaS y retirarte a los seis meses, llegas tarde a la fiesta del código y ni siquiera has empezado la del producto.

Construir no ha sido nunca el problema.

Vender lo que construyes, sí.