Lovable a producción: qué falla, qué arreglar primero y una lista de comprobación

Llevar una app de Lovable a producción significa cerrar los huecos con los que un prototipo puede vivir, pero los usuarios reales no: cada tabla de la base de datos protegida con Row Level Security (RLS), ninguna clave secreta enviada al navegador, comprobaciones en el servidor para todo lo que toque dinero o datos personales, pagos confirmados por webhooks y copias de seguridad y alertas activadas. En la mayoría de los casos se trata de reforzar, no de reescribir.

El orden importa más que la longitud de la lista. Primero la exposición de datos, luego los secretos, después los pagos y al final todo lo que mantiene la app en marcha. Aquí tienes ese orden, una lista de comprobación, los puntos del RGPD para usuarios europeos (y lo que conviene saber si vendes en Latinoamérica), lo que cuesta mantener la app en vivo y una visión honesta de cuándo seguir con prompts y cuándo pasar el trabajo a ingenieros.

Qué significa producción para una app de Lovable

Una demo funciona cuando la recorres tú. Una app en producción sigue funcionando cuando la usan desconocidos de formas que no previste. Cuatro preguntas sirven de prueba:

• ¿Puede un segundo usuario, con su propia cuenta, ver o cambiar tus datos? La respuesta debe ser no.
• ¿Puede alguien que abra las herramientas de desarrollo del navegador encontrar una clave que le dé más permisos que a un usuario normal? Tampoco.
• Si un pago falla, se reintenta o se falsifica, ¿tu base de datos sigue diciendo la verdad?
• Si la app se cae a las dos de la madrugada, ¿te enterarás antes que tus usuarios?

Si no puedes responder las cuatro con seguridad, la app no está lista, por pulida que se vea.

Los fallos que aparecen primero

El problema más habitual no es exótico: una base de datos que cualquiera puede leer. Un investigador analizó 1.645 apps del escaparate público de Lovable y encontró 170 con tablas de Supabase legibles usando solo la clave pública, un fallo registrado como CVE-2025-48757. La clave pública está pensada para ser pública; la protección debe venir de las políticas de RLS en cada tabla.

Y esa protección a menudo falta. Un análisis de seguridad afirma que Lovable crea tablas sin activar Row Level Security ni crear políticas y señala la falta de RLS como el principal fallo de seguridad de Lovable. Siga o no tu proyecto ese patrón, tienes que revisar cada tabla tú mismo.

Los otros sospechosos habituales:

• Secretos en el front end. Las claves de pagos, correo o IA puestas en el código del cliente acaban en el paquete que cualquiera puede descargar.
• Validación solo en el navegador. Un formulario que comprueba un precio o un rol en el navegador se salta con una sola petición editada.
• Sin límites de peticiones. El registro, el inicio de sesión y cualquier endpoint que use una API de pago pueden bombardearse hasta disparar tu factura o tu bandeja de entrada.
• Un solo entorno. Probar cambios directamente en la base de datos en vivo es la forma en que se borran datos reales.

Orden de prioridades: qué arreglar primero

Las listas publicadas van desde una lista de nueve arreglos de un ingeniero sénior (secretos en el servidor, RLS, autenticación real, CORS, límites de peticiones, CI/CD, observabilidad y escalado de la base de datos) hasta una de 47 puntos en nueve áreas y otra de 12 comprobaciones antes de que lleguen usuarios reales. Se solapan mucho, pero casi nunca dan un orden. Trabaja por riesgo:

La lista de refuerzo

Base de datos y autorización

• Activa RLS en todas las tablas, incluidas las que crees que no se usan.
• Escribe políticas que vinculen cada fila a su dueño (por ejemplo, un usuario solo lee filas cuyo ID de propietario coincide con el suyo).
• Prueba con dos cuentas reales: entra como usuario B e intenta cargar los registros del usuario A cambiando IDs en la URL o en la petición.
• Revisa igual los buckets de almacenamiento de archivos; tienen sus propias reglas de acceso.
• Protege las acciones de administración con una comprobación de rol en el servidor, no con un botón oculto.

Secretos y lógica en el servidor

• Busca en el código todo lo que parezca una clave secreta y muévela a funciones de servidor o variables de entorno.
• Rota cualquier clave que haya estado en el código del cliente, aunque fuera un momento. Da por hecho que la copiaron.
• Recalcula precios, totales y permisos en el servidor. Nunca confíes en un valor que envía el navegador.
• Restringe CORS a tu propio dominio.

Pagos

• Da acceso solo cuando un webhook de tu pasarela confirme el pago, no cuando el usuario llega a la página de éxito.
• Verifica las firmas de los webhooks y haz que los manejadores puedan ejecutarse dos veces sin problema.
• Prueba tarjetas rechazadas, reembolsos y suscripciones canceladas. Las tarjetas europeas suelen pedir un paso extra de autenticación reforzada (SCA), así que prueba también ese flujo. Si vendes en México, Colombia o Argentina, prueba los métodos de pago locales que ofrezcas.

Entornos y despliegue

• Crea un proyecto de staging separado, con su propia base de datos y sus claves.
• Guarda el código en un repositorio Git que controles, para que los cambios queden registrados y sean reversibles.
• Aplica los cambios de base de datos como migraciones, probadas en staging antes de producción.

Copias, monitorización y límites

• Confirma que existen copias de seguridad y, sobre todo, practica una restauración.
• Añade seguimiento de errores y alertas de disponibilidad que lleguen a tu móvil.
• Limita las peticiones de inicio de sesión, registro, recuperación de contraseña y cualquier endpoint que use un servicio de pago.
• Registra quién hizo qué en las acciones sensibles, sin guardar contraseñas ni datos de tarjeta.

RGPD y protección de datos

Si tienes usuarios en España o en cualquier país de la UE, el RGPD se aplica desde el primer registro. Los puntos prácticos:

• Ubicación de los datos. Comprueba en qué región corre tu proyecto de base de datos. Elegir una región de la UE simplifica mucho las transferencias de datos.
• Contratos de encargado del tratamiento. Cada servicio que maneja datos de tus usuarios (base de datos, hosting, correo, pagos, analítica, IA) es un encargado. Firma o acepta sus acuerdos de tratamiento y enuméralos en tu política de privacidad.
• Política de privacidad y cookies. Explica qué recoges, para qué y durante cuánto tiempo. Las cookies no esenciales necesitan consentimiento previo según las normas de ePrivacy.
• Derechos de los usuarios. Asegúrate de poder exportar y borrar los datos de un usuario a petición, incluidos los archivos subidos, e indica cuánto tiempo los conservan las copias de seguridad.
• Preparación ante brechas. El hueco de RLS descrito arriba es justo el tipo de incidente que puede obligar a notificar. Arreglarlo también es cumplimiento.

En Latinoamérica, varios países tienen leyes propias de protección de datos personales con principios parecidos; revisa la del país donde están tus usuarios. Esto no es asesoramiento legal; en sectores regulados como salud o finanzas, consulta con un especialista.

Costes de mantenimiento tras el lanzamiento

A noviembre de 2026, Lovable tiene un plan gratuito, y los de pago empiezan en 25 $/mes por Pro con 100 créditos, con un plan Business por encima; todos los planes incluyen 20 créditos Cloud al mes para alojar el backend, y los dominios propios requieren un plan de pago. El plan gratuito da 5 créditos diarios, con un máximo de 30 al mes, y muestra una insignia de Lovable en tu app, sin acumulación de créditos ni recargas; Pro añade dominios propios, quitar la insignia, acumulación y recargas.

Para una app en vivo, presupuesta más que el constructor: un plan de pago para el dominio y la insignia, el uso de base de datos y hosting a medida que crece el tráfico, el nombre de dominio, el envío de correos, el seguimiento de errores y las comisiones de pago. Estos precios están en dólares estadounidenses, así que calcula el cambio de divisa y comprueba si se añaden impuestos al pagar.

Arreglarlo tú o pasarlo a ingenieros

Puedes avanzar buena parte de la lista con prompts si sabes leer el código generado, hacer la prueba de las dos cuentas y entender por qué funciona una política. Confiar solo en prompts es arriesgado cuando la herramienta dice que algo está arreglado y no tienes forma de comprobarlo.

Conviene pasar el trabajo a ingenieros si se cumple alguna de estas condiciones:

• Manejas datos de salud, financieros o de menores.
• Cobras pagos o gestionas suscripciones.
• Has encontrado un problema de RLS o de secretos y no sabes cuántos más hay.
• Inversores, un cliente corporativo o un departamento de compras te harán preguntas de seguridad.
• Necesitas ser dueño del código y poder moverlo sin depender de una herramienta.

Si prefieres un coste conocido a una factura abierta de agencia, NOWWWA Studio construye software de producción con ingenieros sénior y el sistema de agentes de NOWWWA. Un MVP a precio fijo cuesta 8.000 €, acordado de antemano, se entrega en unas dos semanas y el código es entero tuyo. Para trabajo continuo, la Build Subscription cuesta 4.000 €, facturada cada dos semanas. Si quieres ver la dirección antes de comprometerte, el prototipo rápido empieza con un depósito de 99 € que se descuenta del precio de construcción. Reservar una conversación para repasar tu app de Lovable es la forma más sencilla de saber qué camino te conviene.