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.
Las herramientas de vibe coding (Lovable, Bolt, v0, Replit, Cursor) son extraordinarias para llegar a algo que se puede enseñar. 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.
La base de datos está 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. Si no lo está, esa clave pública sirve para leer y escribir cualquier tabla.
- 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.
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.
La configuración de la vista previa no es la de 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. 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. 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.