Tu app hecha con IA se ha roto: ¿rescatarla o rehacerla?

¿Qué suele fallar cuando se rompe una app hecha con IA?

Las apps generadas con Lovable, Bolt, Replit, v0 o Cursor fallan casi siempre en los mismos sitios: la herramienta optimiza una demo que luce en pantalla, no el trabajo con usuarios reales, datos reales y un segundo desarrollador. El síntoma rara vez es la causa; empieza por esta tabla.

No es mala suerte. En las pruebas de Veracode de 2025 con más de 100 modelos de lenguaje, el 45 % de las muestras de código suspendió los controles de seguridad. GitClear, sobre 211 millones de líneas modificadas, vio el código copiado y pegado pasar del 8,3 % al 12,3 % entre 2020 y 2024, y esa duplicación deja vivo en un sitio el error corregido en otro.

¿Qué hacer en las primeras 48 horas?

Ordena por daño, no por molestia: una página lenta pierde algunas visitas; una base de datos abierta, los datos de tus clientes.

1. Congela y copia: deja de pedirle al constructor que «lo arregle» en producción, lleva el código a un repositorio Git tuyo y haz copia de la base de datos.
2. Cierra las fugas: rota toda clave que haya pasado por el navegador o el repositorio, mueve las llamadas secretas al servidor, activa RLS en cada tabla pública y compruébalo sin sesión.
3. Protege los datos: busca registros duplicados o huérfanos y pon borrar, reembolsar y editar en bloque detrás de una comprobación de rol.
4. Mantén el servicio: añade registro de errores y recorre a mano el inicio de sesión, el pago y el flujo de pedido.
5. Solo entonces, velocidad: índices, paginación y caché.

Si pueden haberse filtrado datos personales de personas en la UE, el artículo 33 del RGPD da al responsable 72 horas desde que tiene constancia para notificarlo a la autoridad de control (en España, la AEPD), salvo que sea improbable que suponga un riesgo para las personas. La notificación la redacta un abogado; un desarrollador te dice qué quedó expuesto y desde cuándo.

Rescatar o rehacer: ¿cómo se decide?

Revisa cinco señales. Si dos o más caen en la columna de la derecha, pide un presupuesto para rehacer antes de pagar más arreglos.

El argumento clásico de Joel Spolsky contra reescribir: el código viejo guarda años de correcciones halladas con el uso real. Una app generada en dos fines de semana no tiene esa historia; su valor está en los datos, en los flujos de los que dependen tus usuarios y en lo aprendido. Rehacerla derrocha, pues, menos de lo que parece, si la app actual sigue funcionando mientras tanto.

La vía intermedia más segura es lo que Martin Fowler llama strangler fig (higuera estranguladora): piezas nuevas y probadas asumen un flujo tras otro detrás de la app en marcha. La regla de una guía de limpieza: limpiar mientras el total no pase de 5.000 dólares y rehacer cuando las estimaciones superen los 8.000 y la app se hiciera en pocos días.

¿Cuánto cuesta un rescate en el mercado en 2026?

Son precios de oferta publicados por empresas que venden este trabajo, no medias auditadas.

¿Por qué tanta diferencia? Nuestros paquetes son acotados y cerrados: un fallo, cinco fallos listados o un rescate que mapea los fallos, protege los flujos críticos y publica los arreglos acordados. Rehacer por 20.000 dólares es otro producto: si el mapa de fallos muestra que hace falta, recibes antes su presupuesto por escrito y el mapa pasa a ser su especificación.

¿Por qué un rescate cuesta diez veces más que otro?

Axonbuild contó unos 3,4 problemas críticos por app, más unos 40 hallazgos opcionales, en 21 apps hechas con IA auditadas en junio y julio de 2026. Esos pocos críticos marcan el precio; su dificultad depende de esto:

• Roles: con administradores, empleados y clientes, cada regla se revisa rol por rol.
• Varias empresas cliente en una base: separar inquilinos cuesta 3.000–8.000 dólares en la lista de vibecoding.app.
• Pagos y webhooks: se prueban en el entorno de pruebas del proveedor antes de tocar nada.
• Integraciones: cada una suma claves, límites y fallos.
• Accesos: Git, una copia de pruebas y los registros valen más que capturas y una contraseña compartida.
• Momento: según la misma guía, limpiar antes del lanzamiento sale de dos a cinco veces más barato.

¿Se puede seguir desarrollando con IA después del rescate?

Sí. Hasta los desarrolladores desconfían: en la encuesta de Stack Overflow de 2025, al 66 % lo que más le frustra son las respuestas de IA «casi correctas, pero no del todo». Mantén la IA y pon controles entre el prompt y producción:

• Cada cambio pasa por Git y una pull request, aunque lo escriba la IA.
• Los tests de inicio de sesión, pago y flujo principal frenan una versión que falla.
• Los secretos viven en el servidor; el navegador solo recibe claves públicas.
• Cada versión se comprueba antes de publicarse y se puede revertir.
• Una persona que lee código aprueba los cambios en reglas de datos y permisos.

Esa red sin rescate la monta el servicio de QA y automatización de pruebas, por 73 $ asistido por IA o 93 $ dirigido por especialistas.

¿Qué enviar para recibir un presupuesto preciso?

• Acceso de lectura al repositorio, o una exportación del constructor.
• El stack: constructor, base de datos, hosting, autenticación y pagos.
• Tres fallos en pasos: qué hiciste, qué esperabas y qué obtuviste.
• Los flujos que traen dinero o contactos, por orden.
• Cuántos usuarios hay y qué datos personales se guardan.

No pegues contraseñas en un chat: crea cuentas de colaborador que puedas revocar tras la entrega.

¿Cuándo no deberías pagar un rescate?

• La app no tiene usuarios y solo probaba una idea: apunta lo aprendido y rehazla limpia a partir de una buena especificación.
• El fallo es de la plataforma: escribe primero al soporte del constructor.
• Necesitas una función nueva, no una reparación: eso es desarrollo y se presupuesta como tal.
• Vas a cambiar de rumbo: rescatar código que tirarás el mes que viene es pagar dos veces.

Desconfía de quien promete arreglarlo todo en un día sin leer el código.