Por qué dejé Lovable

Qué es y por qué importa

Lovable es cómodo. El motivo por el que lo dejé es otro: dentro de una plataforma así, el código vive en su casa, el deploy pasa por ellos y los precios los deciden ellos. Yo prefiero un proyecto que esté en una carpeta mía.

Para mí, hace un año esa comodidad tenía sentido, porque las otras herramientas eran difíciles. Hoy con Claude Code pido las mismas cosas que le pediría a Lovable, escribiendo como en un chat, y al final el proyecto es mío: me lo llevo donde quiero.

Es una elección mía, no una regla. Si estás a gusto donde estás, quédate: esta guía te sirve igual, porque tener una copia tuya de todo nunca está de más.

La cuestión es que un proyecto no es solo el código: están los datos, las cuentas de los usuarios, los archivos subidos, las claves, el dominio. Cada pieza sale por una puerta distinta, y si te olvidas de una, te das cuenta cuando un usuario ya no puede entrar.

Una regla antes que nada: no borres nada hasta que lo nuevo funcione.

1. El código en un GitHub tuyo

En Lovable: Project settings → Git → GitHub. Conectas tu cuenta y haces que cree el repositorio: Lovable lo crea privado y lo mantiene sincronizado en los dos sentidos, lo que cambias en Lovable va a GitHub y viceversa.

En Replit: Tools → Git. Si el proyecto aún no tiene repositorio, pulsa «Initialize Git Repository». Luego conectas GitHub (la primera vez Replit te pide que lo autorices), haces un commit y el push de todos los archivos.

Luego clonas el repositorio en tu ordenador, desde el botón «Code» de la página del repo en GitHub. A partir de aquí es una carpeta tuya.

2. La base de datos: estructura y datos

El código lleva la estructura de la base de datos, no los datos. En Lovable la estructura está en las migrations, archivos SQL normalmente en la carpeta supabase/migrations. Los datos, es decir, las filas de verdad, los exportas aparte.

Sin los datos tienes una app vacía.

En Lovable Cloud la exportación de la base de datos está en la configuración avanzada del Cloud: More → Cloud → Overview → Advanced settings → Export data. El enlace llega por correo: es un archivo de copia de seguridad de Postgres, con estructura y datos, y se restaura con pg_restore. Los archivos subidos y las claves se quedan fuera: los llevas a mano, como explico más abajo.

En Replit las bases de datos son dos. La de desarrollo la usas mientras construyes. La de producción la usa la app publicada, y ahí están los datos de tus usuarios: esa es la que hay que exportar.

Abre la herramienta Database y elige la de producción. En la pestaña My Data puedes exportar los datos a un archivo. En la pestaña Settings está la cadena de conexión: según la documentación de Replit, a la base de datos de producción se puede conectar cualquier cliente compatible con PostgreSQL, así que también pg_dump. Trátala como una contraseña.

Lo importas en un Postgres o Supabase tuyo, nuevo y vacío.

3. Variables de entorno y claves

Las variables secretas no salen ni con el código ni con la exportación de la base de datos. Y en Lovable los secretos no se pueden volver a leer, solo sustituir: el valor lo sacas del servicio que te lo dio.

En Replit las encuentras en Tools → Secrets, con los valores visibles. Si la app está publicada, revisa también los secretos de producción en la configuración de Publishing: pueden ser distintos.

Haz la lista de todas: base de datos, API, pagos, correo. Ponlas en el .env del ordenador y en la configuración del nuevo hosting, nunca en el código.

Cuando la app nueva funcione, regenéralas todas y revoca las viejas: han pasado por otra plataforma y ya no sabes dónde han acabado.

4. Usuarios, archivos, dominio

Los usuarios

Las cuentas de inicio de sesión no viajan con las tablas: si solo mueves los datos, los usuarios se quedan atrás.

La exportación completa de Lovable Cloud, en cambio, los incluye, con las contraseñas cifradas. Si la restauras en un proyecto de Supabase, los usuarios conservan su contraseña; las sesiones no, así que todos volverán a iniciar sesión.

En Replit, en Tools → Users & Auth, pestaña Users, ves quién se ha registrado. Con Replit Auth los usuarios entran con una cuenta de Replit. Sus filas en la base de datos viajan con los datos, la forma de entrar no: decide antes el nuevo inicio de sesión y cómo hacer volver a los que ya están.

Si llegas por otro camino y las contraseñas no se pueden llevar, prepara un correo de «restablece tu contraseña» para enviar el día del cambio.

Los archivos subidos

Fotos, documentos, avatares: no están en la base de datos ni en el código. En Lovable Cloud los encuentras en More → Cloud → Storage. Descárgalos y vuelve a subirlos al nuevo almacenamiento, en buckets (las «carpetas» del almacenamiento) con los mismos nombres.

En Replit están en App Storage: Tools → App Storage, elige el bucket en el menú de arriba a la izquierda y en la vista Objects descargas cada archivo con el icono de al lado.

Luego cuenta los archivos antes y después.

El dominio

Apunta dónde está registrado el dominio y copia sus registros DNS actuales antes de cambiarlos. En Replit el dominio conectado está en Publishing, pestaña Domains. Si lo compraste dentro de la plataforma, mira cómo se transfiere antes de cerrar nada.

5. Abre la carpeta con Claude Code

Abre el terminal en la carpeta del proyecto y arranca Claude Code (cd a la carpeta y luego claude). Lee los archivos solo. Yo le doy estas peticiones, en este orden.

Lee todo el proyecto y explícame cómo está hecho: framework, base de datos, inicio de sesión, servicios externos. Hazme la lista de las variables de entorno que hacen falta.

Este es el mapa. En los proyectos de Replit la app suele encontrar la base de datos en la variable DATABASE_URL: en el nuevo tendrá que apuntar a la tuya.

Crea un archivo .env.example con todas las variables, sin valores reales, y añade .env al .gitignore.

El .env.example solo tiene los nombres. Los valores reales están en el .env, en tu ordenador, y el .gitignore le dice a git que no lo suba nunca.

Ponlo en marcha en local. Si algo depende de la plataforma vieja, dime qué y propónme cómo sustituirlo.

Aquí salen las cosas escondidas: un inicio de sesión que pasa por la plataforma, una dirección escrita en el código. Cuánto pregunta Claude Code antes de actuar depende del modo de permisos, que cambias con Shift+Tab. Cuando pregunte, lee lo que va a hacer antes de decir que sí.

Importa el dump de la base de datos en una base de datos local y comprueba que las páginas muestren los datos reales.

Necesitas Postgres en el ordenador: si no está, pide a Claude Code que te ayude a instalarlo. Luego abre la app: si ves tus usuarios y tus contenidos, los datos están.

6. Publica donde mandas tú

Prepara el deploy en [Vercel / tu servidor]: dime los pasos, las variables que hay que configurar y qué cambiar en el DNS. No toques nada hasta que te diga ok.

La última frase cuenta: primero quiero leer el plan. También puedes usar el plan mode (Shift+Tab, o /plan delante del prompt): Claude escribe un plan y no modifica los archivos hasta que lo apruebes.

Antes de mover el dominio, prueba todo en la dirección que te da el nuevo hosting: inicio de sesión con una cuenta vieja, un archivo subido, los pagos en modo de prueba. Luego, solo cuando la nueva versión funcione, en este orden:

1. Mueves el dominio y añades la nueva dirección a las URL de redirección que autoriza tu inicio de sesión.
2. Regeneras las claves y revocas las viejas.
3. Apagas la versión vieja.

Errores comunes

• Exportar de Replit la base de datos de desarrollo. Los datos de la app publicada están en la de producción: exporta esa.
• Escribir los valores reales en el .env.example. Ahí solo van los nombres; los valores están en el .env, que git ignora.
• Olvidar cómo entran los usuarios. Decide antes el nuevo inicio de sesión y cómo vuelven a entrar los que ya están registrados.
• Copiar las claves viejas en el nuevo y darlo por terminado. Regenéralas y revoca las viejas.

Lista de comprobación

• Código en un GitHub tuyo, privado, clonado en el ordenador
• Estructura y datos exportados de la base de datos de producción
• Lista de variables y .env.example sin valores reales
• Usuarios, archivos y registros DNS guardados
• App en local con los datos reales
• Inicio de sesión, archivos y pagos probados en el nuevo hosting
• Dominio movido, claves regeneradas, la versión vieja apagada la última

Preguntas frecuentes