Tienes una app a medias hecha con Lovable, Bolt o Cursor. Cada arreglo rompe otra cosa y empiezas a pensar en borrarlo todo. Antes de hacerlo: la decisión no es «todo o nada», y casi nunca se decide por lo feo que parezca el código. Se decide mirando cuatro sitios.
Arreglar o rehacer una app hecha con IA se decide por el modelo de datos, no por lo feo que esté el código: si las tablas representan tu negocio y los permisos se pueden escribir sobre ellas, se rescata; si la lógica está repartida por las pantallas, se rehace por capas; y solo si el modelo no representa el negocio se rehace entero, conservando diseño, flujos y textos.
El momento es reconocible. Le pides a la IA que arregle el carrito y deja de funcionar el registro. Le pides que arregle el registro y vuelve a fallar el carrito. Llevas semanas así y la tentación es abrir un proyecto nuevo y «hacerlo bien esta vez».
A veces es la decisión correcta. Muchas veces no. Y lo que la decide no es si el código se ve desordenado — el código generado casi siempre se ve desordenado — sino si los cimientos representan tu negocio. Eso se comprueba en cuatro sitios concretos.
¿Solo hay dos opciones? No, son tres
«Arreglar o rehacer» deja fuera la salida más habitual: rehacer por capas. Mantener lo que ya funciona (pantallas, flujos, textos) y sustituir lo que está podrido, normalmente la capa de datos y permisos. Es menos épico que empezar de cero y casi siempre más rápido. Las herramientas se comparan en hasta dónde llega cada una.
Para saber cuál de las tres te toca, mira estas cuatro señales por orden. La primera pesa más que las otras tres juntas.
El modelo de datos: ¿cuenta la verdad de tu negocio?
Abre las tablas de la base de datos y pregúntate si alguien de tu sector las entendería. Si vendes reservas, ¿hay una tabla de reservas con su estado, su cliente y su fecha? ¿O la reserva vive repartida entre tres tablas y un campo de texto con JSON dentro?
- Cada concepto del negocio tiene su sitio, y uno solo. No hay
clientesycustomersconviviendo. - Las relaciones existen de verdad (claves ajenas), no como un nombre copiado en otra tabla.
- Los datos que importan no están en campos de texto libre que nadie puede consultar.
- Hay datos de usuarios reales que habría que migrar si rehaces. Cuantos más, más cara la reescritura.
Si el modelo es razonable, casi todo lo demás se puede arreglar encima. Si no representa el negocio, cada pantalla que construyas encima heredará el problema. Es la única señal que, por sí sola, justifica rehacer.
La estructura: ¿la lógica tiene casa?
El patrón típico del código generado (y una de las 9 causas por las que estas apps fallan en producción): cada pantalla habla directamente con la base de datos, a su manera. La regla de «un pedido no puede cancelarse si ya se envió» está escrita en tres componentes, y en dos de ellos de forma distinta. Por eso cada cambio rompe otra cosa: no hay un único sitio donde vivan las reglas.
Esto no es motivo para tirarlo todo. Es motivo para rehacer por capas: sacar las reglas a un sitio común (un servicio, unas funciones de servidor) y que las pantallas lo usen. Las pantallas se quedan; lo que cambia es lo que hay detrás.
La autenticación y los permisos: ¿quién puede ver qué?
Aquí está el riesgo de verdad. Muchas apps hechas con estas herramientas usan Supabase, donde la clave pública va en el navegador y lo que protege los datos es la seguridad a nivel de fila (RLS). Si está desactivada o mal escrita, cualquiera con esa clave lee lo que no debe. La lista completa está en la seguridad de una app hecha con Lovable, Bolt o Supabase.
La pregunta para decidir no es si hay fallos — los suele haber — sino si los permisos se pueden expresar sobre el modelo actual. Si cada fila sabe a quién pertenece, escribir las políticas es trabajo acotado. Si no hay forma de saber de quién es un dato sin recorrer media aplicación, el problema vuelve a la señal 01.
Los tests: ¿algo avisa cuando se rompe?
En la mayoría de proyectos generados no hay ninguno, así que esta señal rara vez decide por sí sola. Lo que sí dice es cuánto cuesta cada cambio: sin tests, cada arreglo es una apuesta. Antes de tocar nada en un rescate, lo primero es escribir tests de lo que, si falla, cuesta clientes: registro, login, pago, permisos. Esos tests sirven también si rehaces: son la especificación de lo que la versión nueva tiene que seguir haciendo.
Lo que se conserva casi siempre
Aunque acabes rehaciendo el código entero, hay trabajo hecho que no se tira. A menudo es lo más caro de conseguir:
- El diseño. Colores, tipografía, componentes de interfaz. Si ya gustan, se reutilizan tal cual o casi.
- Los flujos validados. El orden de las pantallas que tus primeros usuarios ya entienden. Cambiarlo «porque ahora lo hacemos bien» es tirar aprendizaje.
- El texto. Los mensajes, los botones, la ficha de producto. Se escribieron probando y corrigiendo; no se reescriben gratis.
- Las decisiones de producto. Qué se quitó y por qué. Anótalo antes de empezar o la versión nueva lo volverá a añadir.
¿Cómo es una auditoría seria y qué tienes que recibir?
Una auditoría seria no es «le he echado un vistazo y hay que rehacerlo». Es un documento que puedes leer, discutir y enseñar a otro proveedor. En Relevo, nuestro servicio para estos proyectos, la auditoría ocupa los primeros cinco días y es por escrito. Esto es lo que se mira:
- El modelo de datos frente a lo que hace el negocio.
- Los permisos: políticas de la base de datos, claves expuestas en el navegador, qué ve cada rol.
- Dónde vive la lógica y cuánta está duplicada.
- La configuración de producción: variables de entorno, dominios, URLs de redirección del login.
- Qué se rompe al probar los flujos principales de punta a punta en un dispositivo real.
Y lo que tienes que recibir al final: qué se queda, qué se tira y cuánto cuesta cada opción. Con eso decides tú, no quien te lo va a cobrar. En nuestro caso, al día siguiente llega un presupuesto cerrado con precio y fecha antes de tocar una línea.
Los errores típicos al reescribir
Si la auditoría dice que toca rehacer, el peligro cambia de sitio. Estos son los clásicos, y algunos tienen nombre desde hace décadas.
El efecto del segundo sistema
Fred Brooks lo describió en 1975 en «The Mythical Man-Month»: el segundo sistema que diseña alguien tiende a cargarse con todo lo que se quedó fuera del primero. En una reescritura suena así: «ya que empezamos de cero, metemos también los pagos recurrentes, el panel de analítica y la app nativa». Resultado: la versión nueva tarda el triple y el producto que funcionaba se queda congelado mientras tanto. La versión nueva tiene que hacer lo mismo que la vieja, bien hecho. Lo nuevo, después.
Perder lo que ya estaba validado
Joel Spolsky lo contó en el año 2000, en «Things You Should Never Do, Part I», a propósito de Netscape, que decidió reescribir su navegador desde cero: el código feo esconde arreglos de casos raros que costó encontrar con uso real. En una app hecha con IA pasa igual a pequeña escala: ese if extraño puede ser el arreglo del usuario que se registraba dos veces. Antes de borrar, haz la lista de comportamientos que funcionan y conviértela en tests.
Repetir el método que trajo el problema
Abrir un proyecto nuevo en la misma herramienta y pedirle lo mismo con otras palabras suele llevar al mismo sitio. Si rehaces, empieza por lo que faltó la primera vez: el modelo de datos escrito y revisado, los permisos definidos por rol y los tests de lo crítico. La IA puede seguir escribiendo mucho código; lo que no puede es decidir eso por ti.
Olvidarse de los usuarios que ya tienes
Si hay gente usando la app, rehacer incluye migrar sus cuentas y sus datos sin que lo noten. Es trabajo propio, con su prueba y su plan de vuelta atrás. Si no está en el presupuesto, el presupuesto está incompleto.
¿Cuál es la regla rápida para decidir?
Si tuviéramos que resumirlo en un solo esquema, sería este:
Empezar de cero parece barato porque lo caro ya lo pagaste: aprender qué querían tus usuarios. No lo tires con el código.
Preguntas frecuentes sobre rescatar o rehacer una app hecha con IA
¿Cuándo conviene rehacer una app hecha con IA en vez de arreglarla?
Cuando el modelo de datos no representa el negocio y los permisos no se pueden expresar sobre él: es la única señal que por sí sola justifica rehacer. Si el fallo es de configuración, permisos o robustez, se rescata. Si la lógica está repartida por las pantallas, se rehace por capas y se conserva la interfaz.
¿Qué se conserva al rehacer una app?
Casi siempre el diseño (colores, tipografía, componentes), los flujos que tus primeros usuarios ya entienden, los textos y las decisiones de producto, es decir, qué se quitó y por qué. Es trabajo hecho a base de probar y corregir, y suele ser lo más caro de conseguir: se reutiliza aunque se reescriba todo el código.
¿Qué debe incluir una auditoría de una app hecha con IA?
Un documento escrito que revise el modelo de datos frente al negocio, los permisos y las claves expuestas, dónde vive la lógica y cuánta está duplicada, la configuración de producción y los flujos principales probados en un dispositivo real. Al final tienes que saber qué se queda, qué se tira y cuánto cuesta cada opción.
¿Cómo saco el código de Lovable o Bolt antes de decidir?
Lo primero es copiarlo a un repositorio tuyo. Lovable sincroniza en los dos sentidos con GitHub, GitLab o Bitbucket, y Bolt se conecta a GitHub para guardar el proyecto con su historial fuera de la herramienta. Ese repositorio es lo que se audita, lo decidas como lo decidas.
¿Por qué suelen salir mal las reescrituras completas?
Por dos motivos que conocemos desde hace décadas: el efecto del segundo sistema, que carga la versión nueva con todo lo que quedó fuera de la primera, y perder arreglos de casos raros que el código viejo ya tenía. Por eso la versión nueva debe hacer primero lo mismo que la vieja, y lo nuevo, después.
Fuentes
- Sync your Lovable project with GitHub — Lovable Docs · consultado el 3 de octubre de 2026
- GitHub for version control — Bolt Support · consultado el 3 de octubre de 2026
- Row Level Security — Supabase Docs · consultado el 3 de octubre de 2026
- The Mythical Man-Month — Wikipedia · consultado el 3 de octubre de 2026
- Things You Should Never Do, Part I — Joel on Software (6 de abril de 2000) · consultado el 3 de octubre de 2026