App de Lovable a producción: qué corregir antes del lanzamiento

Lovable permite describir una app y verla aparecer: pantallas, registro de usuarios, una base de datos e incluso pagos. Para un fundador, esa velocidad es realmente valiosa. La trampa es que un prototipo y un producto son cosas distintas. Un prototipo tiene un solo usuario, datos de prueba amigables y ninguna consecuencia. Un producto tiene desconocidos, datos personales y una reputación que proteger.

Esta guía está pensada para fundadores que quieren llevar una app de Lovable a producción y dejarla lista para producción sin improvisar. Si desea una primera lectura rápida de su situación, ejecute antes nuestro AI App Health Check gratuito. Señala las áreas de abajo que más atención necesitan. Lovable y Supabase evolucionan rápidamente, así que verifique cualquier detalle específico de la plataforma con la configuración de su propio proyecto y la documentación vigente.

Prototipo frente a producción: qué cambia realmente

Lovable es un constructor de apps con IA que suele combinarse con Supabase para la autenticación, una base de datos Postgres y el almacenamiento de archivos. Esa combinación traslada buena parte de la responsabilidad de seguridad a la configuración: políticas de base de datos, ajustes de redirección, claves de API y reglas de almacenamiento. El constructor genera el código, pero no puede ver a sus usuarios reales, su dinero real ni sus errores reales.

Que una app esté lista para producción significa que cada una de esas configuraciones ha sido probada por alguien que intenta romperla. Las secciones siguientes siguen el orden en el que los problemas suelen doler.

Dónde suelen necesitar atención de ingeniería las apps creadas con Lovable

1. Seguridad a nivel de fila (RLS) en Supabase

Es lo primero que hay que comprobar. En una configuración con Supabase, el navegador habla con la base de datos mediante una clave pública, y las políticas de seguridad a nivel de fila (RLS) deciden qué puede leer o escribir cada usuario. Una tabla sin políticas, o con políticas que lo permiten todo, puede exponer los datos de todos sus clientes.

Pruébelo con dos cuentas. Cree al cliente A y al cliente B con registros separados. Inicie sesión como B e intente abrir, editar y eliminar los registros de A cambiando los ID en las URL y llamando a la API directamente. Si algo de eso funciona, tiene un bloqueo para el lanzamiento. Nuestra guía sobre los siete errores de RLS de las apps creadas con IA explica los patrones que hay que buscar, entre ellos los roles almacenados donde los usuarios pueden editarlos y los buckets de almacenamiento demasiado abiertos.

2. Autenticación, URL de redirección y flujos de correo

La autenticación que funciona en una URL de vista previa a menudo falla, o peor, se comporta de forma laxa, en su dominio real. Compruebe lo siguiente:

• La URL del sitio y la lista de URL de redirección permitidas incluyen su dominio de producción, y no direcciones de vista previa obsoletas ni comodines que ya no necesita.
• La confirmación por correo, los enlaces mágicos y el restablecimiento de contraseña funcionan de principio a fin en producción, y los enlaces de restablecimiento caducan y no pueden reutilizarse.
• Los correos de autenticación se envían desde su propio dominio con SPF, DKIM y DMARC configurados, para que no acaben en spam. El remitente de correo por defecto suele estar pensado para pruebas y no para tráfico real; revise la configuración de su proyecto.
• Las acciones exclusivas de administración se aplican en el servidor o mediante políticas de base de datos, y no solo se ocultan en la interfaz.

3. Secretos y qué llega al navegador

Todo lo que se empaqueta en el frontend es público. Una clave pública (anon) de Supabase está diseñada para ser visible, pero solo es segura si sus políticas RLS son correctas. Una clave service-role, una clave secreta de pagos o una clave de un proveedor de IA en el código del frontend es una fuga grave. Busque claves en su JavaScript compilado y en el historial del repositorio, rote todo lo que haya estado expuesto alguna vez y traslade las llamadas que requieren secretos a funciones del lado del servidor. Ponga límites de gasto a cualquier clave de IA o de API de terceros.

4. Webhooks de Stripe y derechos de acceso

Un flujo de pago que funciona en modo de prueba no está terminado. El acceso de pago debe derivarse de eventos de webhook verificados, no de la página de éxito a la que llega el navegador. Confirme que se verifican las firmas, que las entregas repetidas se gestionan de forma segura y que las renovaciones fallidas, las cancelaciones y los reembolsos modifican el acceso correctamente. Las claves de prueba y las de producción nunca deben mezclarse. Los detalles están en nuestra guía sobre webhooks y suscripciones de Stripe en apps creadas con IA.

5. Estructura del código generado, duplicación y pruebas

El código generado suele funcionar, pero se repite: componentes similares copiados con pequeñas diferencias, reglas de negocio dispersas por la interfaz y ausencia de pruebas automatizadas. No es una emergencia el primer día, pero es la razón por la que un cambio pequeño puede romper algo sin relación. Antes de escalar, añada pruebas en torno a las rutas de dinero y de permisos, reúna las reglas duplicadas en un solo lugar y mantenga los cambios de base de datos en migraciones bajo control de versiones, de modo que el esquema pueda recrearse y revisarse.

6. Rendimiento y monitorización de errores

Una demo con diez filas es rápida. Los datos reales dejan al descubierto consultas que lo traen todo, índices de base de datos ausentes y páginas que cargan demasiado. Añada monitorización de errores y alertas de disponibilidad que lleguen a una persona, para enterarse de un fallo antes de que se lo diga un cliente. Compruebe las páginas de listados con volúmenes de datos realistas, no con filas de ejemplo.

7. Despliegue, dominios y copias de seguridad

Decida dónde se ejecuta la app, quién puede desplegar y cómo se vuelve a la última versión que funcionaba. Mantenga separados staging y producción, cada uno con su propia base de datos y sus propias claves. Confirme la configuración de su dominio y de HTTPS, active las copias de seguridad de la base de datos y restaure una de verdad para ver cuánto tarda. Una copia de seguridad que nunca ha restaurado es una esperanza, no un plan.

8. Propiedad del código, repositorio y exportación

Asegúrese de que es dueño de lo que está construyendo. Conecte el proyecto a un repositorio en una cuenta que usted controle, confirme que puede ejecutar la app fuera del constructor y mantenga el proyecto de Supabase, el registrador de dominios y la cuenta de pagos bajo accesos de la empresa, no de una persona o un contratista. Las funciones y condiciones de Lovable cambian, así que consulte la documentación vigente. Tener el código en su propio repositorio también facilita mucho empezar cualquier trabajo de ingeniería posterior.

Qué puede seguir resolviendo con prompts y cuándo contratar a un ingeniero

Siga usando prompts para el trabajo en el que un error es visible y barato: diseño, textos, colores, pantallas nuevas que solo muestran a cada usuario sus propios datos y pequeñas funciones de contenido. Revise el resultado, conserve una versión a la que pueda volver y evite pedir a la herramienta que reescriba lo que ya funciona.

Incorpore a un ingeniero cuando un error sería invisible o costoso: políticas de base de datos, ajustes de autenticación, cualquier cosa que toque pagos, migraciones que modifican o borran datos, secretos y cualquier área donde cada arreglo parece romper otra cosa. Si no sabe explicar quién puede ver qué en su app, eso por sí solo es motivo suficiente. Tratamos esta decisión con más detalle en cuándo dejar de usar prompts y recurrir a un ingeniero, y la lista completa de comprobaciones en la lista de 20 puntos para dejar una app lista para producción.

Un camino de rescate paso a paso

1. Auditar. Obtenga una revisión independiente del control de acceso, las políticas de datos, los pagos, los secretos y el despliegue. El resultado debe ser una lista priorizada con los pasos para reproducir cada problema, no una puntuación vaga.
2. Corregir los problemas críticos. Cierre primero todo lo que exponga datos o dinero: políticas ausentes o permisivas, claves filtradas, webhooks sin verificar.
3. Reforzar. Añada pruebas para las rutas de permisos y de facturación, traslade los secretos y la lógica sensible al servidor, y configure migraciones, staging, monitorización y copias de seguridad.
4. Lanzar. Publique con un plan de reversión, un responsable designado y alertas que alguien atienda. Si puede, empiece con un grupo reducido de usuarios reales.
5. Mantener. Las dependencias, los cambios de plataforma y las nuevas funciones no dejan de llegar. Decida quién aplica las actualizaciones y vigila los errores, ya sea su equipo o un plan de mantenimiento.

Fíjese en lo que falta: una reescritura. La mayoría de las apps pueden repararse sobre la marcha, y una auditoría es la forma de saber si la suya es una de ellas.

Cómo encaja UnlockLive

UnlockLive IT trabaja desde Toronto con un centro de ingeniería en Dhaka, y esta es exactamente la etapa en la que prestamos apoyo.

• La auditoría técnica de apps con IA (AI App Technical Audit) es el primer paso: revisamos su configuración de Lovable y Supabase, probamos las áreas de riesgo y le entregamos una lista priorizada de correcciones que podrá ejecutar con nosotros o sin nosotros.
• El servicio AI App Repair and Launch lleva esa lista hasta el final: corrige los problemas críticos, refuerza la app y la pone en marcha en una infraestructura que usted controla.

Si no está seguro de necesitar alguno de los dos, una auditoría técnica también es distinta de una prueba de penetración; nuestra comparación de auditorías, pruebas de penetración y revisiones de código explica cuál se ajusta a su situación.

Empiece con una comprobación gratuita

Antes de gastar en nada, averigüe dónde se encuentra. Nuestro AI App Health Check gratuito lleva unos minutos y señala las áreas de su app de Lovable que más necesitan una revisión más a fondo. Después use la lista de arriba para probar usted mismo lo que desconoce, y recurra a un ingeniero para las partes que no pueda verificar. Dejar una app de Lovable lista para producción consiste, sobre todo, en encontrar los problemas mientras la única persona afectada es usted.