Tu app de Lovable o Bolt funciona en la demo pero no en producción: por qué pasa y qué mirar

Montaste tu app con Lovable, Bolt o v0. En el editor iba fina: los botones respondían, los datos aparecían, la enseñaste y todo el mundo contento. Le das a publicar, entras con tu dominio y... pantalla en blanco. O un botón que no hace nada. O un cartel de error que no habías visto nunca. Y lo peor: en el editor sigue yendo perfecta, así que no entiendes qué ha cambiado.

Es de las cosas más frustrantes que hay, porque parece que la app "funcionaba" y de repente no. Vamos a ver por qué pasa esto casi siempre, qué puedes mirar tú en diez minutos, y cómo saber si es algo que se arregla en una tarde o hace falta que lo mire alguien.

Por qué va en la demo y se cae al publicar

Piensa en la vista previa del editor como una cocina de exposición: todo está enchufado, el agua sale, las luces encendidas, pero es de mentira. Producción es tu casa de verdad, donde tú tienes que dar de alta la luz y abrir la llave del agua. La app es la misma; lo que cambia es lo que tiene alrededor.

Hay cuatro diferencias que explican el 90% de los casos:

• Las claves y conexiones. Tu app habla con otros servicios (una base de datos, un sistema de correo, pagos). Esas conexiones necesitan claves. En el editor van puestas por arte de magia; en producción, si no las copias tú, la app se queda muda.
• La base de datos. Muchas veces la demo funciona contra una base de datos de juguete llena de datos de ejemplo. Al publicar, o apunta a la de verdad (que puede estar vacía o distinta) o sigue apuntando a la de pruebas y no guarda nada útil.
• Los permisos. Dentro del editor eres el único usuario y puedes verlo y tocarlo todo. En producción entra gente real, y si las reglas de quién puede ver qué no están puestas, o la app no deja hacer nada o —peor— lo deja ver todo a todos.
• Los datos y el volumen reales. En la demo hay tres registros de ejemplo y tú haciendo una cosa cada vez. En producción hay cientos de filas, campos vacíos que no esperabas y varias personas a la vez. Lo que no se probó, salta.

Sabiendo esto, ya no buscas "el fallo" a ciegas: buscas cuál de estos cuatro es. Y para eso hay un orden.

Qué mirar primero

Antes de escribir a nadie, esto lo puedes comprobar tú aunque no sepas programar. La herramienta más útil es gratis y la tienes ya: en el navegador, pulsa F12 y ve a la pestaña Console. Ahí la app te cuenta en rojo lo que le falla, muchas veces con el nombre exacto de lo que falta. No hace falta entenderlo todo; con leer si dice "key", "database" o "permission" ya sabes por dónde va.

Esta tabla empareja el síntoma que ves con lo que suele ser y dónde mirar:

Ese último punto merece un aviso: si tu app guarda datos de personas y va montada sobre Supabase, unas políticas de acceso mal configuradas pueden dejar la base de datos a la vista de cualquiera, sin que en el uso normal se note nada. Es de lo primero que conviene revisar, no por el fallo visible, sino por lo que no se ve.

Un ejemplo con números

Pongamos un caso tipo, inventado para que se entienda. Una tienda pequeña monta con Bolt un catálogo con 200 productos y un formulario de pedidos. En la demo mete 3 productos de ejemplo y hace 1 pedido de prueba: perfecto.

La publican y pasan tres cosas. Una: el formulario no guarda ningún pedido, porque la clave de la base de datos no se copió a producción. Dos: al arreglar eso, aparecen los 3 productos de ejemplo y no los 200 reales, porque la app seguía apuntando a la base de datos de pruebas. Y tres: cuando por fin cargan los 200, la página tarda una eternidad, porque nadie probó qué pasa con volumen de verdad.

Ninguno de los tres es "la app está mal". Son tres piezas de configuración que la demo daba por hechas. Cada una se resuelve por separado, en orden, y ninguna obliga a empezar de cero. Eso es lo normal, no la excepción.

¿Está mal hecha o tiene arreglo?

Casi siempre tiene arreglo. Rescatar una app hecha con IA raras veces significa rehacerla: significa dejar puesto lo que faltaba y ordenar lo que quedó a medias. El propio diagnóstico suele decir también cuánto no hace falta tocar.

Hay una señal, eso sí, para preocuparse un poco: si llevas semanas pidiéndole cambios a la IA y cada arreglo rompe otra cosa, no es mala suerte. Suele querer decir que la base sobre la que sigues construyendo se ha vuelto frágil, y seguir echándole cambios encima empeora la situación en vez de arreglarla. Ahí es cuando compensa que alguien mire el conjunto antes de gastar otra tarde dando vueltas al mismo bug.

Y aun en ese caso, "mirar el conjunto" no es sinónimo de tirarlo. Casi nunca hay que rehacerlo todo; a veces una parte, y con el porqué por delante.

Qué puedes hacer tú y cuándo pedir ayuda

Con lo de arriba ya puedes: leer la consola, comprobar que las claves están puestas en producción y en modo real (no de pruebas), y verificar que la app apunta a tu base de datos y no a la del editor. Solo con eso se resuelve una buena parte de los sustos del primer día.

Pide ayuda cuando la consola diga cosas que no entiendes y no den pista, cuando guardes datos de usuarios y no tengas forma de saber si están protegidos, o cuando cada cambio rompa el anterior. No son fallos tontos: son justo el terreno donde una tarde perdida se convierte en semanas.

Si estás en ese punto, lo podemos mirar sin compromiso: nos mandas el enlace de Lovable, Bolt o v0 (o el repositorio, si lo tienes) y te decimos qué hay, qué falta para producción y cuánto costaría dejarlo andando, con cifra cerrada. Cómo lo enfocamos está en la página del servicio, y si prefieres escribir directamente: contact@easybyte.es.