¿Reescribir o arreglar tu app hecha con IA? Cómo decidir
Cómo decidir si conviene reparar o rehacer una app hecha con Lovable, Bolt, Cursor o Replit: señales a revisar, una tabla de puntos y el camino intermedio.
Read in English →
Casi todas las apps hechas con herramientas de IA conviene arreglarlas, no reescribirlas. Rehacer desde cero solo tiene sentido cuando el modelo de datos está mal desde la base, cuando el código no se puede probar ni desplegar fuera de la herramienta, o cuando la app tiene que hacer algo que su tecnología actual no permite. Si las pantallas funcionan y los problemas están en unas pocas capas (permisos, pagos, manejo de errores), arreglar es más rápido, más barato y mucho menos arriesgado.
En esta guía te damos una forma de decidir con datos y no con cansancio: las preguntas que hay que responder, una tabla sencilla de puntos, lo que implica de verdad cada camino y la opción intermedia, que muchas veces es la más práctica.
¿Por qué reescribir parece la solución?
Cuando la app se rompe cada vez que le pides un cambio a la IA, empezar de nuevo suena a borrón y cuenta nueva. El problema es que una reescritura tira a la basura lo que funciona junto con lo que no. Pantallas, textos, flujos que tus usuarios ya conocen, casos raros que descubriste a golpes: todo eso hay que volver a construirlo y probarlo.
Además, reescribir congela tu producto. Mientras se construye la versión nueva, la vieja sigue necesitando arreglos, así que terminas pagando dos apps. Y la nueva tendrá sus propios errores, que solo aparecen cuando la usan personas reales.
Eso no quiere decir que reescribir nunca sea lo correcto. Quiere decir que la decisión debe salir de lo que está mal en el código, no de lo harto que estés de él.
¿Qué debes revisar antes de decidir?
Responde estas seis preguntas. Muchas puedes contestarlas tú; para el resto basta con una o dos horas de un desarrollador.
- ¿El modelo de datos tiene sentido? Abre las tablas de tu base de datos. ¿Cada cosa del negocio (un cliente, un pedido, una reserva) tiene su tabla con columnas claras, o la misma información está copiada en varios lugares? Los datos duplicados o contradictorios son lo más caro de corregir después.
- ¿El código puede salir de la herramienta? Conecta el proyecto a GitHub, clónalo e intenta ejecutarlo en una computadora normal. Si compila y corre, un desarrollador puede trabajar en él. Si solo funciona dentro de la herramienta, esa es una limitación real.
- ¿Los permisos se validan en el servidor? Si un usuario con sesión iniciada puede leer o modificar datos de otros llamando directamente a la API, es grave, pero casi siempre se corrige con políticas en la base de datos y validaciones en el servidor. Nuestra guía sobre qué hacer si un usuario ve datos de otro explica cómo probarlo.
- ¿Cuánto del código se usa de verdad? Los bucles con la IA suelen dejar varias versiones de la misma función. Un desarrollador puede medir cuánto es código muerto. Mucho código muerto es limpieza, no motivo para rehacer.
- ¿La tecnología sirve para lo que viene? Una app web que ahora necesita funcionar sin conexión en el teléfono, o procesar tareas pesadas en segundo plano, quizá ya superó su base.
- ¿Hay usuarios y datos reales que dependen de ella? Cuanta más gente la usa hoy, más cuesta reescribir, porque también necesitas un plan para migrar sus datos.
¿Cómo puntúas la decisión?
Suma un punto a la columna que se cumple en cada fila. Es una guía aproximada, no una fórmula, pero mantiene la conversación honesta.
| Señal | Suma para arreglar | Suma para reescribir |
|---|---|---|
| Modelo de datos | Claro en general, algo de duplicación | Las entidades principales están mal o mezcladas |
| Corre fuera de la herramienta | Sí, con algo de limpieza | No, o solo con mucho trabajo |
| Flujos principales | Funcionan casi siempre | Fallan de formas que nadie sabe explicar |
| Seguridad | Faltan políticas, hay claves expuestas | Toda la seguridad confía en el navegador |
| Tecnología vs. planes | El mismo tipo de app, con más funciones | Otro tipo de app (sin conexión, tiempo real, nativa) |
| Usuarios activos | Sí, con datos que debes conservar | Pocos o ninguno |
Si la mayoría de los puntos cae del lado de arreglar, arregla. Si cae del lado de reescribir, sobre todo en las dos primeras filas, rehacer merece un presupuesto serio. Si queda repartido, sigue leyendo.
¿Qué implica arreglar de verdad?
Un buen arreglo es más que parchar el error que se ve. Suele seguir este orden:
- Estabilizar. Poner el código en control de versiones, separar pruebas de producción y asegurarte de poder desplegar y volver atrás.
- Asegurar. Agregar políticas por fila o validaciones en el servidor, sacar los secretos del frontend y rotar cualquier clave expuesta.
- Desenredar. Quitar código duplicado y muerto, para que el próximo cambio toque un lugar y no cuatro.
- Proteger lo crítico. Escribir algunas pruebas para el registro, el pago y lo que más hacen tus usuarios.
- Seguir construyendo. Desde ahí puedes volver a tu herramienta de IA, o trabajar con un desarrollador, sobre una base que aguanta.
Cada paso deja la app más segura por sí solo, así que ves avances desde la primera semana en lugar de esperar meses por una versión nueva.
¿Cuándo sí conviene reescribir?
Reescribir vale lo que cuesta en pocas situaciones claras:
- El modelo de datos no puede representar tu negocio sin trucos, y cada función nueva lo empeora.
- El código está atrapado en una herramienta y no se puede exportar ni ejecutar en otro lado.
- El producto cambió tanto que la mayoría de las pantallas ya no tienen que ver con él.
- La app es pequeña y todavía no tiene usuarios, así que rehacerla es rápido y no hay nada que migrar.
Aun así, una reescritura debe aprovechar lo que pueda: diseños, textos, los datos de la base y la lista de casos raros que fuiste juntando.
¿Existe un camino intermedio?
Sí, y muchas veces es la opción más práctica. En lugar de elegir una cosa u otra, reemplazas la parte peor y conservas el resto. Ejemplos típicos:
- Mantener el frontend y rehacer la lógica del backend detrás de endpoints claros.
- Mantener la app, rediseñar el esquema de la base de datos y migrar los datos en un paso planificado.
- Mantener la app web y construir una app móvil nueva contra el mismo backend.
A esto a veces se le llama patrón "estrangulador": las piezas nuevas van reemplazando a las viejas mientras la app sigue en línea. Reparte el costo en el tiempo y tus usuarios nunca dejan de tener un solo producto. Si el problema son sobre todo atajos acumulados, nuestra guía sobre la deuda técnica del vibe coding explica cómo pagarla por etapas.
Respuestas rápidas
¿Sirve rehacerla con otra herramienta de IA? Solo si la nueva herramienta resuelve el problema concreto que encontraste. Pasar de un constructor a otro suele repetir las mismas debilidades.
¿Cuánto tarda tomar la decisión? Revisar el código de una app típica hecha con IA lleva días, no semanas. La decisión debe tomarse antes de pedir cualquier presupuesto grande.
¿Puedo seguir usando Lovable o Bolt después del arreglo? Sí. El objetivo es una base lo bastante sólida para que el siguiente prompt no la rompa.
¿Y si dos desarrolladores me dicen lo contrario? Pregúntale a cada uno qué filas de la tabla revisó y qué evidencia vio en el código.
¿Quieres una segunda opinión sobre tu app?
Usa el chequeo gratuito de tu app para ver lo que se nota desde afuera. Para decidir con el código en la mano, nuestra App Rescue Audit (USD 299) te entrega un informe escrito en 2 días hábiles, y te devolvemos el dinero si no encuentra ningún problema de severidad media o alta. A partir de ahí podemos ayudarte con un MVP rehecho o con mantenimiento continuo. Si todavía lo estás pensando, revisa cuánto cuesta arreglar una app hecha con IA o escríbenos.
