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.
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.
No son dos opciones, 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.
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: 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 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 (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 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.
La regla rápida
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.