Lovable, Bolt, v0: Cuando los MVPs vibe-coded se convierten en una hipoteca de deuda técnica

Las aplicaciones vibe-coded como Lovable, Bolt y v0 son excelentes para prototipos y pésimas como MVPs de producción. Cuando heredamos una, la reconstruimos desde cero cada vez, porque corregir la estructura, los hooks y la autenticación cuesta más que empezar de nuevo. Este artículo traza la línea entre el prototipo que estas herramientas pueden sostener y el MVP que no pueden.

Ahora todos somos programadores. Un fundador sin formación técnica puede describir un SaaS en inglés sencillo el sábado por la mañana y tener algo en una URL pública antes del almuerzo. Eso es un cambio real en cómo se inicia el software, y en su mayoría es positivo. También ha producido un nuevo modo de fallo que no existía hace dos años: aplicaciones en producción que nadie en la empresa puede leer.

Cada semana hablamos con fundadores que lanzaron una build de Lovable, firmaron sus primeros tres clientes y luego chocaron contra un muro que no saben describir. La plataforma hizo el trabajo. La plataforma también tomó cada decisión arquitectónica antes de que el fundador supiera cuáles eran las que importaban.

Este artículo no ataca a Lovable, Bolt ni a v0. Tienen su lugar en la etapa de prototipo. Trazaremos la línea desde el punto de vista del comprador: qué entregan estas herramientas frente a lo que un MVP necesita para sobrevivir a su primer cliente de pago, más el patrón de limpieza que vemos en cada codebase que heredamos.

• El vibe-coding gana en la etapa de prototipo, donde la velocidad supera a la estructura y nada llega a los clientes.

• Los MVPs fallan de forma diferente a los prototipos. La autenticación, la multitenencia, un panel de administración y la observabilidad son innegociables en cuanto un cliente real inicia sesión.

• El coste de limpieza es el coste de reconstrucción. Reconstruimos desde cero cada MVP vibe-coded que heredamos. La build de Lovable fue un coste hundido, no tiempo ahorrado.

• El patrón es consistente. Estructura deficiente, mal uso de useEffect, re-renders innecesarios, rutas de backend abiertas, autenticación chapucera, en ese orden.

• Use Lovable para lo que hace bien. Demos, mockups internos, exploración de ideas. Contrate ingenieros para cualquier cosa por la que un cliente pague.

Ahora todos somos programadores (y eso está bien en su mayor parte)

La barrera para "construí algo" se derrumbó en 2025. v0 genera un componente Next.js a partir de una captura de pantalla, Lovable arma un backend con Supabase a partir de un párrafo, Bolt ensambla una aplicación desplegada en un solo chat, y Replit Agent ejecuta el ciclo completo hasta que algo compila.

Esto es una ventaja real para la exploración de ideas. Un no-ingeniero que antes tardaba tres semanas en encontrar un freelancer puede pasar tres horas validando la idea en píxeles reales. Un diseñador puede construir la demo para su pitch en lugar de simularlo en Figma. Ninguno de esos casos de uso requiere disciplina de producción.

El problema comienza en el siguiente paso, cuando el prototipo pasa a llamarse "MVP", se muestra a un cliente de pago y se trata como software de producción. Las herramientas no anuncian cuándo se cruza esa línea. El fundador raramente sabe que la cruzó.

La línea del prototipo frente a la línea del MVP

Un prototipo es una pregunta. Un MVP es un contrato.

Un prototipo pregunta: ¿tiene sentido esta idea en píxeles? Se ejecuta localmente, falla ruidosamente y no llega a nadie. El modo de fallo es "detecto que esto está mal y corrijo el prompt". Es un artefacto de aprendizaje, y las únicas personas expuestas son el fundador y un cómplice de confianza.

Un MVP es la primera versión que tocan los clientes de pago. En el momento en que dinero o datos personales cambian de manos, el contrato implícito también cambia. El cliente espera que su inicio de sesión siga funcionando, que sus datos permanezcan privados y que la aplicación no pierda su sesión porque un useEffect se ejecutó dos veces. Estos no son requisitos avanzados, son el mínimo.

La razón por la que la mayoría de las aplicaciones vibe-coded cruzan esta línea en silencio es que la herramienta siguió diciendo "listo para producción" mientras entregaba un prototipo. La verificación que detecta el cruce es humana, no técnica: un fundador que sabe lo que un MVP debe hacer antes de poder cobrar.

Cuando la línea importa financieramente, la decisión correcta es contratar ingenieros, no escribir un prompt más rápido. Ejecutamos builds de MVP en un plazo fijo de 3 a 5 semanas, con autenticación, facturación, panel de administración y observabilidad integrados desde el inicio.

Lo que encontramos realmente en las codebases vibe-coded

Cuando un fundador nos entrega un proyecto de Lovable o Bolt y pide una limpieza, el patrón es tan consistente que sabemos lo que encontraremos antes de que el repositorio termine de clonarse. Cinco problemas, aproximadamente en el orden en que duelen.

Estructura deficiente. Archivos nombrados según el prompt que los generó, componentes anidados cuatro niveles de profundidad sin límite de reutilización, una carpeta "utils" que contiene toda la lógica de negocio de la aplicación. La codebase es una transcripción de cómo pensó la IA, no una descripción de lo que hace la aplicación. Agregar una funcionalidad implica leer la mitad del proyecto para encontrar dónde vive el estado.

Mal uso de useEffect. Cada fetch vive en un useEffect, cada cambio de prop desencadena un refetch, y los efectos dependen de objetos recreados en cada renderizado. La aplicación bombardea el backend con solicitudes duplicadas en el primer pintado, luego se detiene cuando una de esas solicitudes falla en silencio. El patrón se agrava en el momento en que se agregan formularios.

Re-renders innecesarios. El estado de nivel superior vive en un context provider que envuelve toda la aplicación, por lo que cada componente se rerenderiza en cada pulsación de tecla. La aplicación se siente lenta con 10 elementos en una lista e inutilizable con 100. La solución requiere conocimiento real de React que el prompt nunca solicitó.

Rutas de backend abiertas. Tablas de Supabase con RLS deshabilitado o configurado como "authenticated" sin alcance por fila, server actions que confían en un user_id enviado por el cliente, edge functions que aceptan cualquier payload porque la validación vivía en el formulario. Un usuario en una ventana de incógnito puede listar cada fila de la tabla.

Autenticación chapucera. Verificaciones de sesión hechas en el cliente, verificaciones de rol realizadas con comparaciones de cadenas contra campos que la IA inventó, flujos de restablecimiento de contraseña que envían el mismo formato de token a cada usuario, secretos JWT en el archivo .env.example commiteado al repositorio público. A veces la anon key es lo único que separa la aplicación de "ahora soy administrador".

Estos no son casos extremos. Son el resultado mediano de "la IA construyó esto sin un ingeniero en el proceso", tema que abordamos desde el ángulo de ingeniería en por qué el software generado por IA todavía necesita revisión de ingeniería.

"Funciona" es la peor señal en la que puede confiar

La parte peligrosa no es que las aplicaciones vibe-coded se rompan. El código malo falla de forma visible y se corrige. La parte peligrosa es que funcionan. La demo corre, los primeros 10 amigos se registran, el primer cliente paga, y el fundador concluye que la build estaba bien.

La deuda técnica se acumula en silencio hasta que algo la saca a la luz. Los detonadores son predecibles:

• Primer cliente de pago real. Sus datos cruzan su límite de autorización. El límite está ausente o es incorrecto. Se entera por un ticket de soporte, no por una prueba de CI.

• Primera solicitud de funcionalidad tras el lanzamiento. El modelo de datos de la IA asumió un usuario por workspace. El cliente quiere dos. Agregar el segundo usuario toca 14 archivos que nadie leyó nunca.

• Primera revisión de seguridad. Un prospecto B2B solicita documentos SOC2 o un pentest. El pentester encuentra las rutas abiertas en 20 minutos. El trato se estanca o muere.

• Primera necesidad de administración. El fundador necesita reembolsar a un cliente, bloquear un bot o ver los registros de la semana pasada. No hay página de administración, y no hay forma de agregar una sin rehacer el enrutamiento.

• Primer evento de escala. Un artículo de blog llega, el tráfico aumenta y la aplicación cae porque cada renderizado obtiene cada fila. La solución es el problema de re-renders mencionado antes.

Cada detonador convierte deuda invisible en una interrupción, un trato perdido o un reembolso. La tasa de interés de la deuda vibe-coded es variable, y el banco llama en el peor momento.

La regla del 100 % de reconstrucción

Tenemos una regla para los MVPs vibe-coded heredados que no se ha roto ni una vez. Los reconstruimos desde cero.

El razonamiento no es esnobismo, es aritmética. Para rescatar una codebase de Lovable tenemos que leer cada archivo que escribió la IA, documentar el modelo de datos que el fundador nunca vio, desenredar la cadena de useEffect, asegurar las rutas, corregir la autenticación y refactorizar la estructura en algo que un humano pueda extender. Ese trabajo es una reconstrucción completa con una restricción adicional: no romper a los clientes que ya usan la versión defectuosa.

Una reconstrucción limpia en nuestro stack toma de 3 a 6 semanas. Un rescate toma de 8 a 12 semanas, porque cada paso de limpieza está condicionado por el esquema previo y los datos en vivo. Los "ahorros" de la build original de Lovable no existen: se tomaron prestados contra la próxima ronda de trabajo.

El encuadre honesto para un fundador: la build de Lovable pagó por la validación. Consiguió los primeros clientes, y eso tiene valor real. El código en sí es un coste hundido. El MVP comienza ahora.

Cómo es un MVP real

Como referencia, aquí hay uno que entregamos en 6 semanas para OHYP GmbH, un servicio inmobiliario en Berlin que emite certificados de financiación a compradores de propiedades.

La build es una plataforma full-stack con un formulario de financiación de 10 pasos como elemento central de conversión, un panel de administración para gestionar el ciclo de vida de las solicitudes, y generación automatizada de certificados PDF que se entrega al cliente en menos de 24 horas. El stack es Next.js con tRPC para la seguridad de tipos de extremo a extremo, Drizzle sobre Neon Postgres, y Better Auth para la gestión de sesiones. Puntuación de rendimiento Lighthouse 96, carga de página inferior a 1,2 segundos, precio fijo.

Ese plazo no es magia. Alrededor del 85 % de cualquier nuevo proyecto en nuestro stack es conexión que ya existe en el proyecto anterior, porque usamos la misma configuración de Next.js 16, React 19, tRPC v11, Drizzle, Neon, Better Auth, Polar, AI SDK 6 a través de Vercel AI Gateway, e Inngest en cada proyecto. El 15 % restante es el trabajo realmente único para este cliente: la lógica de dominio, el modelo de datos, los flujos de trabajo. Las herramientas de IA aceleran ese 15 % dentro de la estructura existente, no la reemplazan.

Esa es la versión de "MVP nativo de IA" que sobrevive al primer cliente de pago.

Cuándo usar Lovable, Bolt o v0 de todas formas

La decisión no es "herramientas de IA o ingenieros". Es "la herramienta correcta para la etapa en la que se encuentra". Use el vibe-coding para las etapas en las que gana. Use ingenieros para las etapas en las que pierde.

La decisión honesta del fundador es lanzar el prototipo en Lovable, validar, y luego contratar ingenieros antes de que llegue el primer cliente de pago. El error es dejar que "funciona" lleve la build al otro lado de la línea por sí solo.

En webvise, ejecutamos builds de MVP en 3 a 5 semanas sobre el mismo stack que usamos para SaaS de producción. Autenticación, facturación, administración y observabilidad están incluidos desde el primer día. Si tiene una build vibe-coded que funciona hoy pero le está dando problemas, cuéntenos qué está viendo y le diremos si es una limpieza o una reconstrucción. Hasta ahora la respuesta siempre ha sido una reconstrucción.