Dejar Lovable: cómo ser dueño del código de tu app y ampliarlo

Lovable es bueno para llevar un producto a sus primeros usuarios. En algún momento, muchos fundadores chocan con la misma pared: cada cambio rompe otra cosa, una funcionalidad necesita un backend de verdad, o se suma un desarrollador que quiere trabajar en su propio editor. Entonces la pregunta no es si Lovable fue un error. Es cómo tomar el control total de lo que construiste sin empezar de cero.

Este post cubre lo que ya es tuyo, cómo sacar el código y cuándo tiene sentido quedarse. Forma parte de la guía para preparar un prototipo construido con IA para usuarios reales.

¿Qué es realmente tuyo?

Más de lo que la mayoría de los fundadores supone. La integración de Lovable con GitHub crea un repositorio privado para el proyecto, lo mantiene sincronizado en ambos sentidos y lo deja en su lugar si te desconectas: “Tu repositorio se queda en GitHub”, y el código es tuyo para descargarlo, desplegarlo o gestionarlo de forma independiente (Lovable).

Sin embargo, el código es solo una de las cosas sobre las que corre tu app. Antes de tocarlo, haz una lista de todas las cuentas de las que depende la app y revisa quién es el dueño de cada una:

Si alguna de ellas pertenece a un freelancer, a un email personal o a la propia cuenta del constructor, resuélvelo primero. Es el paso más difícil de hacer después, bajo presión.

¿Cómo sacas el código?

El camino que sigue la mayoría de los equipos, en orden:

1. Conecta GitHub y revisa la sincronización. Desde la configuración del proyecto, conecta el repositorio y confirma que los últimos cambios aparecen ahí. Lovable sincroniza una rama a la vez, normalmente la rama por defecto.
2. Ejecútalo localmente. Clona el repositorio, instala las dependencias y crea el archivo de entorno con las variables que usa la app. Una app de Lovable es un proyecto React estándar, así que cualquier desarrollador puede ejecutarla.
3. Despliégalo en tu propio hosting. Conecta el repositorio a un hosting como Vercel o Netlify, configura ahí las variables de entorno y despliega un preview. Prueba el flujo completo: registro, la funcionalidad principal, pagos.
4. Mueve el dominio. Apunta tu dominio al nuevo hosting solo después de que el preview funcione, y conserva el despliegue anterior unos días por si necesitas volver.
5. Decide qué papel tendrá Lovable de aquí en adelante. Puedes seguir usándolo para trabajo de interfaz, ya que los cambios enviados a GitHub se sincronizan de vuelta en Lovable. O desconectarlo y trabajar solo en código. El repositorio se queda en cualquier caso.

Para una app pequeña, la migración en sí suele ser uno o dos días de trabajo. El trabajo que sigue es la parte que las herramientas de IA se saltaron: reglas de acceso a la base de datos, validaciones del lado del servidor y tests. Las diez revisiones antes de los usuarios reales son el punto de partida, junto con la row level security de Supabase y las claves secretas en el frontend.

¿Cuándo deberías quedarte en Lovable?

Quédate mientras el producto todavía está encontrando su forma. Si cambias pantallas todos los días, pruebas ideas con pocos usuarios y nadie más que tú toca el código, la velocidad de Lovable vale más que una base de código limpia.

Migra cuando se cumpla una de estas condiciones:

• Los cambios rompen funcionalidades no relacionadas, y no hay tests que te digan qué se rompió.
• Necesitas lógica de backend que el constructor maneja mal: tareas programadas, procesamiento pesado, integraciones con otros sistemas, permisos complejos.
• Se suma un desarrollador que necesita trabajar con ramas, code review y sus propias herramientas.
• Estás por recibir dinero real o manejar datos sensibles, y necesitas a alguien responsable de cómo se gestionan.

¿Qué cambia después de la migración?

El código deja de ser algo que una herramienta regenera y pasa a ser algo que tu equipo mantiene. Eso implica algunos hábitos que el prototipo no necesitaba: los cambios pasan por pull requests, el schema de la base de datos cambia mediante migraciones en lugar del panel, y cada despliegue es reproducible a partir del repositorio. Nada de esto es pesado, pero es la diferencia entre una app que muestras en una demo y una app que operas.