Tu app de Lovable ya está construida. Producción se decide bajo la línea de flotación: en Supabase

Una app de Lovable que corre sobre Supabase está más cerca de producción de lo que admitirán la mayoría de los ingenieros que la revisen, y más lejos de lo que cree el fundador que la construyó. Los dos errores cuestan dinero. El primero acaba en una reescritura que nadie necesitaba. El segundo pone en producción una base de datos que responde a cualquiera que pregunte.

Escribo desde el lado de quien hereda estos repositorios. Antes de Conectia pasé años en DevOps y respuesta a incidentes en entornos enterprise, y hoy nuestros ingenieros se hacen cargo de productos construidos con IA y los preparan para usuarios reales. Con Lovable el patrón se repite lo bastante como para ponerlo por escrito: las pantallas están bien, el esquema suele ser razonable y casi todo lo que entraña riesgo vive en una capa que el fundador nunca ha mirado.

En una app de Supabase, la política de row-level security es el backend. Cuando se entiende por qué, el resto de la auditoría se ordena sola.

El navegador habla directamente con Postgres, y ese es todo el diseño

Una app típica de Lovable es un front en React que llama a Supabase directamente con una clave pública. No hay en medio un servidor de API que hayas escrito tú. Supabase expone las tablas por HTTP, y lo único que decide qué filas puede leer o escribir cada petición son las políticas de Postgres de cada tabla.

Ese diseño no es un defecto: es lo que permite a un fundador tener un producto funcionando en un fin de semana, y aguanta a escala si las políticas son correctas. La documentación de Supabase pone la condición sin rodeos: una tabla sin RLS y sin políticas sensatas permite a cualquier cliente leer y modificar sus datos. La de Lovable lo dice desde el otro lado: «Missing RLS policies are the most common way app data gets exposed», es decir, la falta de políticas RLS es la vía más habitual por la que se filtran datos.

Y ya ha pasado a escala. En mayo de 2025 un investigador analizó 1.645 apps del escaparate público de Lovable y encontró 170 con tablas que se podían leer o escribir solo con la clave pública. Quedó registrado como CVE-2025-48757. Desde entonces Lovable lanza escaneos de seguridad automáticos al publicar, y su propia página de seguridad dice lo que diría cualquier proveedor honesto: esas herramientas no sustituyen una revisión de seguridad a fondo.

Ya escribí sobre qué falla en general en los MVP hechos con IA. Lovable sobre Supabase falla de maneras lo bastante concretas como para merecer su propia lista.

Antes de arreglar nada, averigua qué es tuyo

La primera pregunta de la auditoría no es técnica: ¿dónde vive esto y quién tiene las llaves?

• ¿Lovable Cloud o tu propio proyecto de Supabase? Desde que Lovable convirtió Cloud en el backend por defecto, muchos fundadores no han abierto nunca un panel de Supabase. La documentación de Lovable recomienda conectar un proyecto propio si quieres la propiedad directa, tu propia facturación o acceso completo al panel de Supabase. En Cloud, la región queda fijada al activarlo y no hay migración en un clic hacia un proyecto de Supabase propio. Conviene decidirlo pronto, antes de que crezcan los datos.
• El repositorio. Conecta GitHub y lleva el repo a una organización de la empresa, no a la cuenta personal del fundador. Lovable sincroniza en los dos sentidos, pero solo una rama a la vez. En cuanto haya ingenieros haciendo commits en el mismo repo, decide quién manda en main. Si la protección de rama rechaza un push de Lovable, el cambio acaba en una rama lovable-sync que alguien tendrá que fusionar: es el comportamiento correcto, y la primera vez sorprende.
• Lo que Git no se lleva. El repo contiene el código y los ficheros de migración; los datos y los ficheros subidos se exportan aparte. Tu estrategia de backups no puede ser «está en GitHub».
• Quién puede entrar. MFA en GitHub y en la organización de Supabase, más de un propietario y una lista de todas las personas con acceso al panel. La checklist de producción de Supabase pide exactamente esto, y son veinte minutos.

Dónde se rompen las políticas, en el orden en que me las encuentro

Los problemas se repiten de una base de datos de Lovable a la siguiente. Ninguno es exótico, y cada uno, una vez localizado, son una o dos horas de trabajo senior.

1. Tablas con RLS desactivado. Suele ser una tabla añadida al final o creada a mano en el editor SQL. El Security Advisor de Supabase las señala; es lo primero que hay que ejecutar.
2. RLS activado y abierto de par en par. Una política que dice «cualquier usuario autenticado puede leerlo todo» pasa el control de «RLS activado» del escáner y aun así entrega cada fila a cada cliente que se registre.
3. Aislamiento multi-tenant por convención. La app filtra por organization_id en el front, mientras que la política solo comprueba que el usuario ha iniciado sesión. Lo correcto es una tabla de pertenencia y una política que deduzca el tenant a partir de auth.uid(), nunca de un valor que envía el cliente.
4. Políticas que confían en user_metadata. Cada usuario puede editar sus propios metadatos, y Supabase advierte expresamente de que no se autorice con ellos. Los roles van en app_metadata o en tablas propias.
5. Vistas y funciones que se saltan el RLS. Las vistas creadas por el usuario postgres ignoran las políticas si no llevan security_invoker = true. Una función security definer expuesta por RPC se ejecuta con los permisos de su propietario. Las dos son herramientas legítimas, y las dos son agujeros cuando nadie las ha elegido a conciencia.
6. Buckets de almacenamiento públicos. Facturas y documentos de identidad en un bucket público están a una URL de cualquiera. El almacenamiento tiene sus propias políticas sobre storage.objects, y hay que auditarlas como si fueran tablas.
7. Políticas correctas pero lentas. Una columna sin índice dentro de una política convierte cada lectura en un escaneo secuencial, y llamar a auth.uid() sin envolverla en un select la evalúa fila a fila. Con cincuenta usuarios no se nota; con cincuenta mil, es un ticket de soporte.

Claves, edge functions y los límites que nadie menciona el día del lanzamiento

La clave secreta se salta el RLS. Supabase distingue ahora una clave publicable, que puede ir en el navegador, de una clave secreta que se salta el row-level security y nunca debe salir de tu control. Busca service_role y sb_secret_ en el bundle compilado. Y apunta la fecha: Supabase retira las claves heredadas anon y service_role a finales de 2026, así que una app que aún las use tiene una migración pendiente, pase lo que pase con el resto de este artículo.

Cada edge function es una frontera de autorización. Lovable escribe edge functions para todo lo que necesita un secreto: pagos, correos, llamadas a un LLM. Guarda las claves como secretos de Supabase, fuera del repositorio, y esa parte está bien resuelta. El hueco está dentro de la función: a menudo se ejecuta con permisos elevados y se fía del payload. Cada una debería verificar el JWT de quien la llama y comprobar que ese usuario puede hacer esa acción antes de tocar la clave secreta.

Las edge functions tienen límites estrictos: 2 segundos de CPU por petición, 256 MB de memoria y 150 o 400 segundos de tiempo total, según el plan. Una exportación a PDF, una cadena larga de llamadas a un LLM o una importación nocturna no van ahí: van a un worker con una cola.

Los rate limits protegen Supabase Auth, no tus funciones. Los endpoints de autenticación vienen con límites por IP razonables. Una edge function que llama a la API de un modelo de pago no tiene ninguno hasta que lo escribes, y eso la convierte en un punto de facturación abierto a cualquiera con sesión. Y luego está el que rompe el día del lanzamiento: sin SMTP propio, el envío de correo integrado de Supabase está limitado a dos correos por hora. Existe para hacer pruebas. Configura tu SMTP antes de la primera campaña, o las confirmaciones de registro dejarán de llegar justo cuando más falta hacen.

Migraciones, entornos y backups: la fontanería que una demo nunca necesita

Lovable escribe los cambios de esquema como migraciones revisadas en supabase/migrations/, que es más de lo que tienen la mayoría de MVP hechos a mano que he auditado. La deriva viene de todo lo que se hace fuera de Lovable: una columna añadida desde el panel, una política retocada a mano a medianoche. La solución es una línea base: comparar el esquema vivo con la carpeta de migraciones usando la CLI de Supabase, hacer commit de la diferencia y, a partir de ahí, cambiar el esquema solo mediante migraciones.

Después, los entornos. En estas apps lo normal es un único proyecto para desarrollo y producción, y así es como un script de prueba acaba borrando filas reales. El branching de Supabase te da una base de datos de preview por pull request y ramas persistentes para staging, y su integración con GitHub aplica las migraciones a producción al fusionar. Añade una CI que compruebe tipos, pase los tests y ejecute tests de políticas contra una base de datos de rama, porque una política sin test es una política que alguien relajará sin darse cuenta.

Los backups deciden cómo de malo será tu peor día. En el plan gratuito no hay backups descargables y el proyecto se puede pausar tras una semana de inactividad. Los planes de pago guardan backups diarios (siete días en Pro), y la recuperación a un punto en el tiempo reduce el peor caso a unos dos minutos de datos perdidos. Haz una restauración de prueba en una rama antes de necesitarla. Un backup que nunca se ha restaurado es una esperanza.

Por último, observabilidad y coste: seguimiento de errores en el front, un ID de petición en el log de cada edge function, pg_stat_statements para las consultas lentas y un tope diario para todo lo que llama a un modelo. A escala, la factura casi nunca la dispara la base de datos: la disparan un cómputo que se ha quedado corto, el tráfico de salida del almacenamiento y unas funciones sin rate limit.

Cuándo quedarse en Supabase y cuándo mover el backend

Alguien, a menudo tu primera contratación senior, propondrá reescribir el backend «como Dios manda». He visto ese consejo quemar un trimestre de runway más de una vez. La respuesta honesta: Supabase es Postgres, y Postgres no es la pieza que falla. Quédate en Supabase cuando el producto sea sobre todo datos con permisos, las políticas se puedan escribir y probar, y la autenticación encaje con tus usuarios. Eso describe a la mayoría de apps de Lovable que he visto.

Mueve la lógica de negocio a un servicio —en Python o en Node, los stacks con los que trabajamos— cuando el dominio ya no quepa en políticas: transacciones de varios pasos entre muchas tablas, procesos largos que superan los límites de las edge functions, integraciones pesadas con terceros o un requisito de cumplimiento que exige una única API auditable delante de los datos. Incluso entonces, pocas veces se abandona Supabase. La base de datos, la autenticación y el almacenamiento se quedan; el navegador deja de escribir directamente en las tablas sensibles y pasa a llamar a tu servicio, ruta a ruta. Es el mismo enfoque incremental que defiendo en monolito o microservicios para un MVP: mover la frontera allí donde está el riesgo, no todo a la vez.

Qué auditaría primero, y en este orden

Si tu app de Lovable aterrizara en mi mesa el lunes, este sería el orden. Importa más el orden que la lista, porque cada paso hace seguro el siguiente.

1. Propiedad, el primer día. Repo en una organización de GitHub de la empresa, proyecto de Supabase (o Lovable Cloud) inventariado, MFA en todas partes y la lista de accesos por escrito.
2. Exposición, días uno y dos. Security Advisor y, después, el RLS y las políticas de cada tabla, los buckets, las vistas, las funciones security definer y una búsqueda de claves secretas en el bundle. Rota todo lo que haya estado expuesto alguna vez.
3. Edge functions. Verificación del JWT y autorización en cada una, rate limits en todo lo que gasta dinero y los procesos largos, fuera.
4. Configuración de la autenticación. SMTP propio, confirmación por correo activada, OTP con caducidad corta, URLs de redirección limitadas a tus dominios y CAPTCHA en el registro.
5. Backups. Plan de pago, PITR si los datos importan y una restauración probada.
6. Migraciones y entornos. Línea base del esquema, staging con branching y CI con tests de políticas en las rutas que tocan dinero o datos personales.
7. Observabilidad y topes de coste. Seguimiento de errores, IDs de petición, revisión de consultas lentas y un tope diario de gasto en modelos.
8. Y entonces, la decisión sobre el backend, con lo que hayan enseñado los siete pasos anteriores y no por gusto.

Un ingeniero senior que ya lo ha hecho antes cubre los pasos uno a cinco en la primera o la segunda semana. En el orden inverso —primero funcionalidades y el perímetro después— el mismo trabajo se va a un trimestre.

El casco está hecho. Revisa bajo la línea de flotación antes de botarlo

Piensa en un barco sobre calzos en el astillero: pintado, equipado, terminado a ojos de quien pasa por delante. Nadie lo bota sin que alguien haya revisado lo que queda bajo la línea de flotación. Lovable te construyó el casco rápido y bien, y respondió a la pregunta difícil: si alguien quiere el producto. Lo que queda es la parte que ninguna demo enseña, hecha en un orden conocido.

Si estás valorando quién debería hacerlo, he comparado las empresas que llevan a producción MVP hechos con IA. O, si esa es la pregunta que tienes delante ahora mismo, este es el equipo que ponemos en productos de startup: ingenieros senior seleccionados con una tasa de aceptación del 3%, que empiezan con una semana de Blueprint para auditar lo que tienes, fijar la arquitectura y dejarte un plan por escrito que puedes ejecutar con nosotros o sin nosotros.