Cómo rescatar una app hecha con IA: el orden que funciona

La app llegó al 80 % en una semana. El último 20 % lleva un mes y no está terminado. Cada prompt que arregla una pantalla rompe otra, los créditos se van en vueltas sobre el mismo error, y ya no despliegas un viernes, o directamente no despliegas, sin contener la respiración. Ese es el momento en que una app hecha con IA necesita un rescate y no otro prompt.

Un rescate no es reescribirla. Si compensa rehacerla es otra decisión, que se toma con números y que está en cuánto cuesta arreglar una app hecha con IA. Este artículo va del otro camino, que es el habitual: rescatar una app atascada conservando lo que funciona, comprobándolo con tests y recuperando la capacidad de cambiarla sin miedo. Si lo tuyo es configurar el primer despliegue, empieza por migrar una app de Lovable a producción. Lo que más importa es el orden. Cada paso abarata el siguiente; saltártelos te devuelve al mismo lío.

Señales de que ya no basta con "un prompt más"

Un arreglo en un sitio rompe algo que no tenía nada que ver, y te enteras por un usuario.
No sabes decir dónde están los datos, quién puede leerlos ni si hay copia.
La app funciona en la vista previa y falla en tu dominio.
Nadie, tampoco la IA, sabe explicar por qué una parte funciona como funciona.
Te da miedo tocar los pagos o el login.

Una de estas es un bug. Tres significan que ya no controlas lo que pasa cuando cambias la app. Si te reconoces aquí, en tu app hecha con IA se ha quedado atascada explicamos por qué pasa.

0. Deja de añadir funcionalidades

Todo lo que se añade durante un rescate se construye sobre un suelo que está a punto de moverse. Congela el alcance mientras dure: los bugs que hacen daño a los usuarios se arreglan, las ideas nuevas van a una lista. Es el paso que más le cuesta a quien fundó el proyecto y el que hace asumible todo lo demás.

1. Hazte con todo

Antes de cambiar una línea, asegúrate de que lo que vas a rescatar es tuyo:

El código en un repositorio Git que controles. Lovable y Bolt pueden conectarse a GitHub; las apps hechas con Cursor, Claude Code o Codex suelen vivir en una carpeta del portátil de alguien, que no es lo mismo. Un repositorio, una rama principal, y la versión desplegada localizable en un commit.
El backend en tus cuentas. El proyecto de Supabase, la cuenta de Stripe, el dominio y el alojamiento tienen que estar a nombre de tu empresa, no del freelance ni de la herramienta.
Una lista de todos los servicios que toca la app, con quién los paga y dónde están sus claves. Las apps hechas con IA los acumulan sin hacer ruido: un proveedor de correo, una API de IA, un bucket de almacenamiento, un segundo proyecto de Supabase "de pruebas" al que producción sigue apuntando.

No es papeleo. Un bug "misterioso" de producción en estas apps resulta a menudo ser un ajuste en una cuenta de la que nadie se acordaba.

2. Cierra los agujeros que exponen datos o dinero

La seguridad va antes que los bugs porque es el único problema que empeora mientras esperas. En las apps hechas con IA se repiten los mismos agujeros:

Claves secretas en el navegador. Compila la app y busca en el resultado los prefijos de claves que nunca deben ser públicas. Las claves secretas y restringidas de Stripe en modo real empiezan por sk_live_ y rk_live_; las claves secretas de Supabase, por sb_secret_:
```
grep -rlE 'sk_live_|rk_live_|sb_secret_' dist/
```
dist/ es la carpeta de compilación por defecto de Vite, que usan las apps de Lovable creadas antes del 13 de mayo de 2026; las más recientes funcionan con TanStack Start. En una app de Next.js, busca en .next/static/: ahí están el JavaScript y el CSS que se sirven al navegador bajo /_next/static/. En cualquier otro caso, busca en la carpeta donde la compilación deja los archivos del navegador. Añade los primeros caracteres de cualquier otra clave secreta que use la app, como la de un proveedor de IA, copiados de su panel. Cada coincidencia es un indicio, no una prueba: comprueba si es una clave real que llega al navegador. Si lo es, lleva la llamada que la usa a una función de servidor y rota la clave, porque quitarla del código no la elimina de las versiones ya publicadas. Si el proyecto sigue usando las claves JWT antiguas de Supabase, mira en los ajustes de la API cuál usa el frontend: la anon está pensada para ser pública, la service_role nunca.
Tablas sin seguridad a nivel de fila, o con políticas que lo permiten todo. Una política con USING (true) no filtra ninguna fila: vale para datos que deben ser públicos, pero no protege en absoluto los datos de cada usuario. La guía del error de RLS muestra las políticas que sí son seguras.
Permisos que solo existen en la interfaz. Esconder el botón de admin no es control de acceso. Cada comprobación tiene que repetirse en el servidor o en la base de datos.
Webhooks de pago sin verificar, de forma que cualquiera puede marcar un pedido como pagado.

La lista completa está en el checklist de seguridad (en inglés). Repásala antes que cualquier otra cosa de este artículo.

3. Asegúrate de poder volver atrás

Para cambiar una app con seguridad hacen falta dos cosas que probablemente no tiene:

Una copia de seguridad que hayas restaurado al menos una vez. Mira qué guarda de verdad tu plan de base de datos y luego haz una copia que controles tú. La guía de copia y restauración de Supabase usa tres volcados, con la cadena de conexión que sale del botón Connect del panel del proyecto:
```
supabase db dump --db-url "$DB_URL" -f roles.sql --role-only
supabase db dump --db-url "$DB_URL" -f schema.sql
supabase db dump --db-url "$DB_URL" -f data.sql --use-copy --data-only \
  -x "storage.buckets_vectors" -x "storage.vector_indexes"
```
Después restáuralos en un proyecto vacío con psql, como indica la misma guía, para comprobar que funcionan. Los archivos subidos no van en estos volcados; la guía los traslada con un script aparte. Una copia sin probar es una esperanza.
Un sitio donde romper cosas que no sea producción. Un segundo proyecto de Supabase y un despliegue de pruebas del mismo código. Si la herramienta de IA puede escribir en la base de datos de producción, un prompt desafortunado puede borrar datos reales.

Y los despliegues deberían salir del repositorio, para que deshacer uno malo sea revertir un commit y no una tarde de reconstrucción.

4. Fija lo que la app hace hoy

Antes de arreglar nada, apunta los recorridos que tienen que seguir funcionando: registrarse, iniciar sesión, pagar, y las dos o tres acciones para las que existe la app. Después convierte cada uno en un test automático de extremo a extremo (Playwright es lo habitual) que se ejecute antes de cada despliegue.

Incluye las rarezas. Los usuarios se acostumbran a la app tal como es, bugs incluidos, y un rescate que "arregla" algo de lo que alguien depende es, para esa persona, un fallo nuevo. Un test que fija el comportamiento actual te permite cambiarlo a propósito y no por accidente.

Estos tests también reducen el riesgo de seguir programando con IA después: si cubren el pago, un agente que lo rompa mientras ajusta un margen hará fallar un test en vez de llegar a producción.

5. Arregla lo que impide lanzar y luego lo que impide crecer

Ahora sí, los bugs, en este orden:

Lo que impide lanzar. Un login que redirige a localhost, pagos que solo funcionan en modo de prueba, correos que no llegan, un dominio que no se verifica. Suele ser configuración más que código; los casos habituales están en migrar una app de Lovable a producción y en el login de Supabase redirige a localhost.
Todo lo que toca datos o dinero. Cobros duplicados, pedidos sin usuario, registros que dos usuarios pueden sobrescribir.
Lo que bloquea la siguiente funcionalidad. La parte de la estructura contra la que choca la hoja de ruta: un segundo tipo de usuario, cuentas de equipo, una integración.

Arregla en trozos pequeños que se publiquen cada uno por su cuenta, con los tests del paso 4 en verde cada vez. Un rescate que desaparece seis semanas y vuelve como un único cambio gigante tiene el mismo riesgo que la reescritura que pretendía evitar.

6. Ordena la estructura al final, y solo donde vayas a trabajar

El código generado por IA está lleno de duplicados: tres formas de llamar a la base de datos, dos formatos de fecha, un componente de 600 líneas. Apetece limpiarlo todo. No lo hagas. Limpia las zonas que va a tocar el trabajo de los próximos meses, unifica un patrón cada vez y deja tranquilo el código feo y estable que nadie necesita cambiar. Ordenar tiene un coste, y solo se recupera donde hay cambios.

7. Recupera la app lista para seguir construyendo

El objetivo no es una app que ya no puedas tocar. Es una que tú, un desarrollador o un agente de IA podáis seguir cambiando sin miedo:

Un README que diga cómo arrancarla, probarla y desplegarla.
Una lista de todas las variables de entorno, con dónde se configura cada valor.
Un archivo de reglas para las herramientas de IA (AGENTS.md, las reglas de Cursor, el conocimiento del proyecto en Lovable) que diga qué patrones seguir y qué tests mantener en verde.
Alguien que sepa qué hacer cuando algo se rompe de noche.

Lo que no conviene hacer

Pedirle a la IA que "lo arregle todo". Sin tests y sin forma de volver atrás, un prompt grande es un cambio grande que nadie puede revisar. Así es como llegaron aquí la mayoría de estas apps.
Empezar por el rediseño. Una interfaz nueva encima de una base de datos abierta es un incidente más bonito.
Saltarte lo de hacerte con todo porque el freelance es majo. Las personas cambian de proyecto; las cuentas se quedan con quien las creó.

Hacerlo tú, o con nosotros

Todo lo anterior se puede hacer en casa si alguien del equipo se maneja con bases de datos, despliegues y tests. Lo difícil suele ser la primera mirada: saber cuáles de las cien cosas que están mal son las cinco que importan.

Esa primera mirada es nuestro rescate de apps hechas con IA: un diagnóstico de 450 € en 48 horas laborables, con un informe por escrito de qué funciona, qué está roto, qué es un riesgo de seguridad real y cuánto cuesta cada arreglo, en el orden de este artículo. Puedes quedarte con el informe y hacer el trabajo tú. Si sigues con nosotros, los 450 € se descuentan y el rescate tiene un presupuesto cerrado para un alcance definido, normalmente entre 1.500 € y 6.000 €. Terminamos tu app; no la rehacemos salvo que los números lo justifiquen, por escrito.