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

Las apps vibe-coded como Lovable, Bolt y v0 son excelentes para prototipos y pésimas como MVPs en producción. Cuando se hereda una, la reconstrucción desde cero es la regla sin excepción, porque sanear 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 cualquiera puede programar. Un fundador sin formación técnica puede describir un SaaS en inglés llano un sábado por la mañana y tener algo en una URL pública antes del mediodía. Eso es un cambio real en cómo arranca el software, y en gran medida es positivo. También ha generado un nuevo modo de fallo que no existía hace dos años: apps en producción que nadie en la empresa puede leer.

Cada semana hay conversaciones con fundadores que lanzaron una build de Lovable, firmaron sus primeros tres clientes y después chocaron contra un muro que no saben describir. La plataforma hizo el trabajo. La plataforma también tomó todas las decisiones arquitectónicas antes de que el fundador supiera cuáles importaban.

Este artículo no ataca a Lovable, Bolt ni a v0. Tienen su lugar en la fase de prototipo. Lo que traza es la línea desde la perspectiva 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 saneamiento que aparece en cada base de código heredada.

• El vibe-coding gana en la fase de prototipo, donde la velocidad supera a la estructura y nada llega a clientes reales.
• Los MVPs fallan de forma distinta a los prototipos. Autenticación, multi-tenancy, panel de administración y observabilidad son innegociables en el momento en que un cliente real inicia sesión.
• El coste de saneamiento es el coste de reconstrucción. Todo MVP vibe-coded heredado se reconstruye desde cero. La build de Lovable fue un coste hundido, no tiempo ahorrado.
• El patrón es constante. Estructura deficiente, mal uso de useEffect, rerenders innecesarios, rutas de backend abiertas y autenticación defectuosa, en ese orden.
• Use Lovable para lo que realmente hace bien. Demos, maquetas internas, exploración de ideas. Para cualquier cosa por la que un cliente pague, contrate ingenieros.

Ahora cualquiera puede programar (y eso es mayormente bueno)

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

Esto supone una ventaja real para explorar 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 maquetarla en Figma. Ninguno de esos casos de uso necesita disciplina de producción.

El problema empieza en el paso siguiente, cuando el prototipo se renombra "MVP", se muestra a un cliente de pago y se trata como software en producción. Las herramientas no avisan cuando se cruza esa línea. El fundador rara vez sabe que la ha cruzado.

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 en local, falla de forma visible y no llega a usuarios. El modo de fallo es "detecto que esto está mal y corrijo el prompt". Es un artefacto de aprendizaje al que solo están expuestos el fundador y algún colaborador de confianza.

Un MVP es la primera versión que tocan los clientes de pago. En el momento en que el dinero o los datos personales cambian de manos, el contrato implícito también cambia. El cliente espera que su sesión siga funcionando, que sus datos permanezcan privados y que la app 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 apps vibe-coded cruzan esta línea en silencio es que la herramienta siguió diciendo "production-ready" mientras entregaba un prototipo. La comprobación que detecta ese cruce es humana, no técnica: un fundador que sabe lo que un MVP debe hacer antes de poder cobrar.

Cuando la línea tiene consecuencias económicas, lo correcto es contratar ingenieros, no buscar un prompt más rápido. Los builds de MVP se ejecutan en un plazo fijo de 3 a 5 semanas, con autenticación, facturación, panel de administración y observabilidad incluidos desde el inicio.

Lo que realmente se encuentra en las bases de código vibe-coded

Cuando un fundador entrega un proyecto de Lovable o Bolt y pide un saneamiento, el patrón es tan consistente que sabemos lo que vamos a encontrar antes de que el repositorio termine de clonarse. Cinco problemas, en el orden aproximado en que hacen daño.

Estructura deficiente. Archivos nombrados según el prompt que los generó, componentes anidados en cuatro niveles sin ningún límite de reutilización, una carpeta "utils" que contiene toda la lógica de negocio de la app. La base de código es una transcripción de cómo pensó la IA, no una descripción de lo que hace la app. Añadir 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 dispara un nuevo fetch y los efectos dependen de objetos recreados en cada render. La app bombardea el backend con peticiones duplicadas en el primer pintado y se bloquea cuando una de esas peticiones falla silenciosamente. El patrón se agrava en cuanto se añaden formularios.

Rerenders innecesarios. El estado global vive en un context provider que envuelve toda la app, de modo que cada componente se vuelve a renderizar con cada pulsación de tecla. La app 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 pidió.

Rutas de backend abiertas. Tablas de Supabase con RLS desactivado o configurado como "authenticated" sin scoping 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 todas las filas de la tabla.

Autenticación defectuosa. Comprobaciones de sesión en el lado cliente, verificaciones de rol mediante comparaciones de cadenas contra campos que la IA inventó, flujos de recuperación de contraseña que envían el mismo formato de token a todos los usuarios, secretos JWT en el archivo .env.example comprometido en el repositorio público. A veces la clave anon es lo único que separa a la app de "ahora soy administrador".

Estos no son casos extremos. Son el resultado mediano de "la IA lo construyó sin un ingeniero en el proceso", algo que se abordó desde el ángulo técnico en por qué el software generado por IA sigue necesitando revisión de ingeniería.

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

Las apps vibe-coded suelen superar la primera demo, y ahí es donde empieza el peligro. La demo funciona, 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 superficie. Los desencadenantes son predecibles:

• Primer cliente de pago real. Sus datos cruzan el límite de autorización. El límite falta o está mal configurado. Se descubre por un ticket de soporte, no por un test de CI.
• Primera solicitud de funcionalidad después del lanzamiento. El modelo de datos de la IA asumió un usuario por workspace. El cliente quiere dos. Añadir el segundo toca 14 archivos que nadie leyó jamás.
• Primera revisión de seguridad. Un prospecto B2B pide documentación SOC2 o un pentest. El pentester encuentra las rutas abiertas en 20 minutos. El acuerdo se paraliza o muere.
• Primera necesidad de administración. El fundador necesita reembolsar a un cliente, bloquear un bot o revisar los registros de la semana pasada. No hay página de administración y no hay forma de añadirla sin rehacer el enrutamiento.
• Primer evento de escala. Un artículo de blog llega, el tráfico se dispara y la app cae porque cada render recupera todas las filas. La solución es el problema de rerenders descrito antes.

Cada desencadenante convierte deuda invisible en una caída del servicio, un acuerdo perdido o un reembolso. El tipo 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

Existe una regla para los MVPs vibe-coded heredados que no se ha roto ni una sola vez: se reconstruyen desde cero.

El razonamiento es aritmético. Para sanear una base de código de Lovable hay que leer cada archivo que escribió la IA, documentar el modelo de datos que el fundador nunca vio, desenredar la cadena de useEffect, bloquear las rutas, corregir la autenticación y refactorizar la estructura hasta convertirla 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 el stack habitual tarda de 3 a 6 semanas. Un saneamiento tarda de 8 a 12 semanas, porque cada paso de limpieza está condicionado por el esquema previo y los datos en vivo. El "ahorro" de la build original de Lovable no existe: estaba pedido prestado contra la siguiente ronda de trabajo.

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

Cómo es un MVP real

A modo de comparación, se entregó un MVP en producción para un servicio inmobiliario que emite certificados de financiación a compradores de viviendas, utilizando un flujo de trabajo personalizado en lugar de un scaffold vibe-coded.

La build es una plataforma full-stack con el flujo de financiación 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 dentro del plazo de servicio comprometido. El stack es Next.js con tRPC para type safety de extremo a extremo, Drizzle sobre Neon Postgres y Better Auth para la gestión de sesiones. El contrato utilizó un modelo de entrega con alcance definido.

Ese plazo no es magia. Alrededor del 85% de cualquier proyecto nuevo en este stack es cableado que ya existe en el proyecto anterior, porque se utiliza 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 encargo. El 15% restante es el trabajo realmente exclusivo de ese cliente: la lógica de dominio, el modelo de datos, los flujos. Las herramientas de IA aceleran ese 15% dentro de la estructura existente; no la reemplazan.

Esa es la versión del "MVP AI-native" que sobrevive al primer cliente de pago.

Cuándo usar Lovable, Bolt o v0 de todos modos

Elija la herramienta según la fase: vibe-coding para demos y exploración, ingenieros para productos de pago.

La decisión honesta del fundador es lanzar el prototipo en Lovable, validar y después 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.

webvise ejecuta builds de MVP en 3 a 5 semanas sobre el mismo stack utilizado para SaaS en 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 hoy funciona pero le da problemas, describa lo que está viendo y recibirá una respuesta directa sobre si se trata de un saneamiento o una reconstrucción. Hasta ahora la respuesta siempre ha sido una reconstrucción.