La vista previa va fina, el enlace que le pasaste a tu socio también. Luego entra el primer usuario de verdad y aparece la pantalla en blanco, el login que no vuelve o la base de datos que cualquiera puede leer. No es mala suerte: son casi siempre las mismas nueve cosas.
Una app hecha con IA falla en producción casi siempre por una de nueve causas: base de datos sin seguridad por fila (RLS), claves secretas en el navegador, configuración de la vista previa distinta de la real, sesiones que caducan, otra firma en la tienda, el optimizador de release, red frágil, llamadas a IA sin límite y falta de tests. Se arregla con configuración, permisos y pruebas, casi nunca rehaciéndolo todo.
Las herramientas de vibe coding (Lovable, Bolt, v0, Replit, Cursor) son extraordinarias para llegar a algo que se puede enseñar. Cada una trae su propio atajo para producción, y lo comparamos en Lovable, Bolt, Cursor y v0: qué falta para producción. Donde flojean es en la fontanería que no se ve: configuración, permisos, firmas, errores de red. En la vista previa esa fontanería la pone la propia herramienta; en producción la tienes que poner tú. De ahí sale casi todo.
¿Está tu base de datos abierta a cualquiera?
Es el fallo más grave y el más frecuente. Muchas apps generadas usan Supabase con la clave pública metida en el código del navegador, que es lo normal — siempre que la seguridad a nivel de fila (RLS) esté activada y bien escrita. Según la documentación de Supabase, una tabla sin RLS en un esquema expuesto la puede leer y escribir cualquier rol con permisos sobre ella. Lo desarrollamos en seguridad de una app de Lovable, Bolt o Supabase.
- Cómo saberlo: en el panel de Supabase, cada tabla debe mostrar RLS activado y al menos una política. Una tabla sin políticas con RLS desactivado es pública.
- Cómo arreglarlo: activar RLS en todas las tablas y escribir políticas del tipo «cada usuario solo ve sus filas». Y probarlas: con la clave pública y sin sesión, una consulta debe volver vacía.
¿Hay claves secretas en el código del navegador?
La clave de OpenAI, la secreta de Stripe o la de servicio de Supabase escritas en un componente de React acaban en el JavaScript que descarga cualquier visitante. Basta abrir las herramientas de desarrollador para copiarlas. El síntoma suele llegar en forma de factura.
Arreglo: todo lo secreto vive en el servidor (una función de Supabase, de Vercel o de Firebase) y el navegador solo llama a esa función. Si una clave ha estado expuesta, no basta con moverla: hay que rotarla. Supabase lo resume así: la clave pública es la que va en el navegador; la secreta se salta la RLS y no debe salir del servidor.
¿Por qué el login funciona en la vista previa y no en producción?
URLs de redirección del login que apuntan a la vista previa, variables de entorno que existen en un sitio y no en el otro, CORS que solo permite el dominio de pruebas. El resultado típico: el login con Google abre, eliges cuenta y vuelves a la pantalla de inicio sin sesión, en bucle.
- Lista todas las variables de entorno y comprueba que existen en producción con el valor de producción.
- Añade el dominio real a las URLs de redirección del proveedor de login y a la lista de orígenes permitidos.
- Prueba el flujo completo en el dominio real, en una ventana de incógnito y en un móvil.
Sesiones que caducan y nadie renueva
En la demo nadie mantiene la sesión abierta más de una hora. En producción, el token caduca, la app no lo renueva y las llamadas empiezan a fallar en silencio: listas vacías, botones que no hacen nada. Usa el cliente oficial del proveedor de login, que renueva solo, en vez de guardar el token a mano en localStorage.
En móvil: la versión publicada lleva otra firma
Esta nos pasó con Pax. En desarrollo el login con Google funcionaba; en la versión de la tienda devolvía «Requests from this Android client application are blocked». Los ocho testers de la prueba cerrada no podían entrar.
La causa: Google Play vuelve a firmar tu app con su propio certificado (Play App Signing), y ni Firebase ni la clave de API restringida conocían esa huella. Solo estaba la de depuración.
La versión optimizada se carga piezas que hacían falta
Otra de Pax: una versión arrancaba y se cerraba al instante, antes de pintar nada. En desarrollo, perfecta. El optimizador de Android (R8) había eliminado un constructor que una librería usaba por reflexión; la documentación de Android lo describe: si la app se cierra tras optimizar con R8, suele ser reflexión rota. Tenemos una guía entera sobre por qué funciona en debug y falla en release. Este tipo de fallo solo existe en la compilación de release, así que si nunca pruebas esa compilación en un móvil real, lo descubren tus usuarios.
La app da por hecho que siempre hay buena red
Pax descargaba sus fuentes tipográficas de internet al arrancar. Una conexión que se cortaba a mitad bastaba para tumbar la app. Lo arreglamos empaquetando las fuentes y con un test que falla si alguien vuelve a pedir una por red. La lección general: cualquier llamada de red en el arranque necesita qué hacer cuando falla — y en un metro, un garaje o una obra, falla.
Llamadas a la IA sin límite
Si tu app llama a un modelo de lenguaje en cada pulsación y no hay límite por usuario, un solo usuario insistente (o un bot) puede costarte en una noche lo que facturas en un mes. Pon un límite por usuario y por día en el servidor, cachea lo que se repite y vigila el gasto con una alerta.
Nada avisa cuando algo se rompe
Cada vez que le pides a la IA un cambio, puede romper algo que funcionaba en otra pantalla. Sin tests de lo importante (registro, login, pago, permisos) y sin un informe de errores como Crashlytics o Sentry, te enteras por un correo enfadado. No hace falta cobertura total: hacen falta tests de lo que, si falla, te cuesta clientes.
¿Rescatar o rehacer desde cero?
Casi nunca hay que tirarlo todo (el razonamiento completo, en rescatar o rehacer una app hecha con IA). La parte visual y el flujo que ya has validado con usuarios valen mucho. Lo que suele haber que rehacer es la capa de datos y permisos. Nuestra regla rápida:
- Rescatarsi el modelo de datos tiene sentido, el producto ya está validado y los fallos son de configuración, seguridad o robustez (los nueve de arriba).
- Rehacer partessi cada pantalla consulta la base de datos a su manera o la lógica de negocio está repartida por los componentes.
- Rehacer enterosolo si el modelo de datos no representa el negocio. Pasa menos de lo que parece.
La IA te llevó al 80 %. El 20 % que falta es el que rompe — y es justo el que se puede auditar.
Preguntas frecuentes sobre apps hechas con IA que fallan
¿Por qué mi app de Lovable o Bolt funciona en la vista previa y falla en producción?
En la vista previa la propia herramienta pone la configuración; en producción la pones tú. Fallan las variables de entorno que no existen en el dominio real, las URLs de redirección del login, el CORS y los permisos de la base de datos. Se detecta probando el flujo completo en el dominio real, en incógnito y en un móvil.
¿Cómo sé si mi base de datos de Supabase está abierta?
En el panel de Supabase, cada tabla de un esquema expuesto debe tener RLS activado y al menos una política. La prueba definitiva es consultarla con la clave pública y sin sesión: debe devolver vacío. Si devuelve filas, cualquiera que abra las herramientas de desarrollador de tu web puede leerlas.
¿Por qué falla el login con Google solo en la versión de la tienda?
Porque Google Play vuelve a firmar la app con su propio certificado (Play App Signing) y Firebase y las claves de API restringidas solo conocen la huella de depuración. Se arregla registrando las tres huellas (depuración, subida y Play App Signing) el primer día en Firebase y en cada clave restringida.
¿Dónde deben guardarse las claves secretas de una app hecha con IA?
En el servidor: una función de Supabase, Vercel o Firebase que el navegador llama sin ver la clave. Las claves de OpenAI, Stripe o la de servicio de Supabase escritas en un componente acaban en el JavaScript público. Si una ha estado expuesta, no basta con moverla: hay que rotarla.
¿Hay que rehacer la app o se puede rescatar?
Casi nunca hay que rehacerla entera. Se rescata si el modelo de datos tiene sentido y los fallos son de configuración, seguridad o robustez. Se rehacen partes si cada pantalla consulta la base de datos a su manera. Solo se rehace todo si el modelo de datos no representa el negocio.
Fuentes
- Row Level Security — documentación de Supabase · consultado el 3 de octubre de 2026
- API keys — documentación de Supabase · consultado el 3 de octubre de 2026
- CVE-2025-48757 — NVD (NIST) · consultado el 3 de octubre de 2026
- Statement on CVE-2025-48757 — Matt Palmer · consultado el 3 de octubre de 2026
- Use Play App Signing — Ayuda de Play Console · consultado el 3 de octubre de 2026
- Troubleshoot app optimization (R8) — Android Developers · consultado el 3 de octubre de 2026