Migrar una app de Lovable a producción: guía realista

"Migrar a producción" es la frase que más se repite cuando una app hecha con IA empieza a ir en serio, y también la que más se malinterpreta. No es pulsar "Publish". Es que la app aguante usuarios reales, con datos reales y dinero real, sin que tú estés mirando.

Esta guía recorre lo que hay que resolver, en el orden en el que conviene resolverlo. Está escrita pensando en Lovable porque es donde más gente se atasca, pero el checklist es el mismo para Bolt, v0, Base44 o una app generada con Claude Code o Codex.

1. Saca el código de la herramienta

Lo primero no es el dominio: es que el código exista fuera de la plataforma. En Lovable, conecta el proyecto a GitHub desde los ajustes; en Bolt y v0, exporta o sincroniza con un repositorio. A partir de ahí tienes tres cosas que antes no tenías: una copia que nadie te puede quitar, un historial de cambios al que volver cuando algo se rompa, y la puerta abierta a que cualquier desarrollador — humano o IA — trabaje sobre la app sin pasar por los créditos de la plataforma.

Si tu app nació ya en la terminal con Claude Code o Codex, este paso es gratis: ya tienes repositorio. Tu problema empieza en el punto 4.

2. Separa la vista previa de la realidad

La mayoría de fallos "misteriosos" al publicar son esto: la app sigue apuntando a la configuración de la preview.

• Variables de entorno. Todo lo que en la preview "estaba ahí" tiene que existir también en el entorno final: claves de Supabase, de Stripe, de OpenAI, URLs base.
• Redirecciones de autenticación. El proveedor de auth (Supabase Auth, Google, etc.) tiene una lista de URLs permitidas. Si solo está la de la preview, el login funciona allí y falla en tu dominio. Añade el dominio final en la configuración del proveedor, no solo en el DNS.
• Dominio y HTTPS. Configura el dominio en la plataforma o en tu hosting, espera a que el certificado esté emitido, y prueba el flujo completo de registro y login desde el dominio real, en una ventana de incógnito.

3. Seguridad antes que features

Es el paso que todo el mundo salta y el que más caro sale saltarse.

• RLS en Supabase. Cada tabla con datos de usuarios necesita Row Level Security activada y políticas escritas y probadas. "Parece que está" no es un estado válido: pruébalo con dos cuentas distintas intentando leer los datos de la otra.
• Claves en el navegador. Cualquier clave que viaje al frontend es pública. Las claves de servicio (Stripe secreta, OpenAI, service role de Supabase) solo pueden vivir en el servidor o en funciones edge.
• Permisos en servidor. Esconder un botón no es un permiso. Toda comprobación de "quién puede hacer qué" tiene que ejecutarse donde se lee o se escribe el dato.

4. Pagos, correos y las fronteras con el mundo

Si cobras con Stripe: verifica la firma de los webhooks, maneja el caso de webhook repetido (Stripe reintenta), y trata la suscripción como estado en tu base de datos, no como un correo que llegó una vez. Si envías correos, usa un dominio verificado (SPF/DKIM) o irán a spam. Estas fronteras son donde las apps generadas con IA fallan más, porque en la vista previa nunca se ejercitan de verdad.

5. Un despliegue que puedas repetir

Producción no es un sitio: es un proceso. La pregunta que lo resume: si ahora mismo tuvieras que desplegar un cambio de una línea, ¿cuántos pasos manuales harías y cuántos podrían salir mal? Para una app Next.js/Supabase típica, el mínimo digno es: repositorio en GitHub, despliegue automático al hacer push (Vercel, un VPS con CI, o el hosting que ya tengas), variables de entorno gestionadas fuera del código y copias de seguridad de la base de datos programadas y — esto es lo que casi nadie hace — restauradas una vez para comprobar que funcionan.

6. Lo que no hace falta (todavía)

Kubernetes, microservicios, colas, multi-región. Una app con sus primeros cientos de usuarios no los necesita, y añadirlos ahora solo multiplica las cosas que pueden fallar. La escala se resuelve cuando duele; la seguridad y las copias, antes de que duela.

Si prefieres no pelearte con esto

Este checklist es exactamente lo que ejecutamos en el rescate de apps hechas con IA: diagnóstico de 450 € en 48 horas laborables con el estado real de tu app punto por punto, y si quieres que la llevemos nosotros a producción, presupuesto cerrado — típicamente entre 1.500 € y 6.000 € según lo que haya que arreglar. Las bandas de precio están explicadas aquí, y si tu app ni siquiera ha llegado a este punto porque está atascada, empieza por por qué se atascan y cómo terminarlas.