Checklist: 15 cosas que revisar antes de abrir tu app de Lovable a clientes reales

Respuesta corta: antes de abrir a clientes una app hecha con Lovable, Bolt o v0, comprueba que todas las tablas de Supabase tienen RLS con políticas por dueño, que no hay claves secretas en el frontend, que el servidor valida lo que recibe y que tienes copias de seguridad que sabes restaurar. Después vienen las pruebas automáticas con despliegue y vuelta atrás, los límites de coste, los textos legales (RGPD, LSSI y AI Act) y, si vas a las tiendas, sus requisitos. Son 15 puntos; los cinco primeros son los que más daño hacen si fallan.

Las herramientas de IA hacen en días un buen prototipo. Lo que no hacen es pensar en quién no debería ver qué, en qué pasa el día que algo se rompe o en lo que pide la ley. Esta lista sale de lo que revisamos al llevar a producción Calma, nuestra propia app, y de los fallos típicos de las apps generadas con IA. Cada punto dice qué revisar, cómo comprobarlo y, cuando lo hay, qué nos encontramos en Calma.

La lista

1. Seguridad

   Row Level Security activado en todas las tablas

   En una app de Supabase el navegador consulta la base directamente con una clave pública. Una tabla sin RLS se puede leer entera desde la consola del navegador, porque la URL del proyecto va dentro de la app. No es teórico: el fallo CVE-2025-48757 describía justo esto en apps generadas con Lovable (Lovable lo discute: dice que proteger los datos es responsabilidad de cada cliente).

   Cómo comprobarlo: en el editor SQL, select relname from pg_class where relnamespace = 'public'::regnamespace and relkind = 'r' and not relrowsecurity; tiene que devolver cero filas. El asesor de seguridad del panel de Supabase también lo marca.

   En Calma: en la auditoría del 26-09-2026 todas las tablas tenían RLS. La conclusión que más nos importó fue otra: con los permisos por defecto de Supabase, RLS es la única barrera. Hay que repetir la auditoría cada vez que entra una tabla o una función nueva.

2. Seguridad

   Políticas que comprueban de quién es cada fila

   Tener RLS activado no basta: una política using (true), o una que sólo pide estar autenticado, deja a cualquier usuario leer los datos de todos los demás. La política tiene que comparar la fila con quien llama, normalmente auth.uid() = user_id, tanto para leer como para escribir.

   Cómo comprobarlo: crea dos cuentas de prueba y, con la sesión de la primera, intenta leer, cambiar y borrar filas de la segunda. Repite sin sesión. Si algo funciona, hay un hueco.

3. Seguridad

   Ninguna clave secreta en el frontend

   La clave anon o publishable de Supabase puede ir en el navegador. Ninguna otra: ni la service_role, que se salta RLS, ni las de OpenAI, Gemini, Stripe o el servicio de correo. Todo lo que lleve el prefijo VITE_ o NEXT_PUBLIC_ acaba en el código que descarga cualquiera.

   Cómo comprobarlo: haz el build y busca en la carpeta de salida (dist/) los prefijos típicos (sk-, AIza, service_role). Si alguna clave estuvo alguna vez en el repositorio, rótala: el historial de git también cuenta.

   En Calma: las claves de la IA, del correo y de Google sólo están en los secretos de las funciones del servidor, y los tokens de acceso al calendario se guardan cifrados en una tabla que ni la propia usuaria puede leer.

4. Seguridad

   El servidor comprueba quién llama y qué le mandan

   La validación del formulario es para la experiencia de uso; la de verdad está en el servidor. Cada edge function tiene que verificar el token de la persona, validar tipos y tamaños y no fiarse de un user_id que venga del cliente. Las funciones de Postgres con SECURITY DEFINER se ejecutan con permisos de administrador: hay que revisar quién puede llamarlas y fijar su search_path.

   En Calma: la auditoría vio que el registro de decisiones de la IA lo escribía el navegador: una usuaria podía inventarse entradas en el suyo. No exponía datos de nadie, pero un registro así no prueba nada. Ahora lo escribe sólo el servidor, y cada despliegue comprueba que las funciones responden 401 o 403 sin sesión.

5. Seguridad

   Autenticación configurada para producción

   Revisa las URL de redirección permitidas (sólo tus dominios), la confirmación de correo, los límites de intentos y los proveedores de inicio de sesión con sus pantallas de consentimiento verificadas. El correo que trae Supabase por defecto está pensado para pruebas y tiene límites muy bajos: para usuarios reales hace falta un SMTP propio.

6. Datos

   Copias de seguridad que has restaurado al menos una vez

   Mira qué copias incluye tu plan de Supabase y cuánto tiempo las guarda. Y, sobre todo, restaura una en una base de prueba: una copia que nunca se ha restaurado es una suposición.

   En Calma: antes de aplicar cada migración en producción, el despliegue guarda una copia de la base en un bucket privado en Madrid que conserva 30 días, y el procedimiento para restaurarla está escrito.

7. Datos

   Migraciones en el repositorio y entornos separados

   Cada cambio en la base es un fichero de migración versionado, no un clic en el panel, y tiene que funcionar también con la versión ya publicada: nada de borrar una columna en el mismo despliegue que deja de usarla. Desarrollo y producción son bases distintas.

   En Calma: cada desarrolladora tiene su Supabase local con cuentas de prueba, y el CI rechaza que se edite una migración ya desplegada.

8. Datos

   Datos personales: los mínimos, y que se puedan borrar y descargar

   Guarda sólo lo que la app necesita, con un plazo de conservación para cada cosa. La persona tiene que poder borrar su cuenta y descargar sus datos, y borrar la cuenta tiene que borrar de verdad todo lo suyo, también en los servicios externos.

   En Calma: borrar la cuenta borra en cascada todas sus tablas y revoca el permiso de calendario en Google; los informes de error se purgan solos a los seis meses como mucho.

9. Escalado y costes

   Topes de uso en todo lo que se paga por llamada

   Un modelo de IA, una API de mapas o el envío de SMS pueden convertir un bucle o un usuario malintencionado en una factura. Pon una cuota por usuario y un tope diario para todo el proyecto, y configura alertas de presupuesto en cada proveedor.

   En Calma: las sugerencias con IA tienen cuota diaria por usuaria y la clave del modelo tiene un tope de 300 peticiones al día para todo el proyecto.

10. Escalado y costes

    Límites del plan y consultas que aguantan el crecimiento

    Lee los límites del plan de cada servicio. Añade índices a las columnas por las que filtras (con RLS, al menos a user_id), no cargues listas enteras en el navegador y calcula el coste mensual antes de lanzar.

    En Calma: el plan gratuito de Supabase pausa los proyectos sin actividad, así que un trabajo programado hace una consulta ligera cada tres días.

11. Despliegue

    Pruebas automáticas que bloquean el despliegue

    Las pruebas son lo que te deja seguir usando la IA para programar sin miedo a romper producción. Como mínimo: que la app compila, pruebas de la lógica importante y pruebas de la base de datos (que las políticas hacen lo que crees). Si fallan, no se despliega.

    En Calma: GitHub Actions pasa las pruebas de la app, de la base, de las funciones y del recomendador en cada pull request y antes de cada despliegue.

12. Despliegue

    Despliegue automático, con vuelta atrás

    Publicar no debería depender de la memoria de nadie. Un pipeline aplica migraciones, funciones y frontend en orden, comprueba que todo responde y, si algo falla, vuelve a la versión anterior. La vuelta atrás hay que ensayarla.

    En Calma: la web se publica primero en un canal de vista previa, se prueba en Chrome, pasa a producción, se vuelve a probar y, si falla, vuelve sola a la versión anterior. Hicimos un simulacro antes de confiar en ello.

13. Despliegue

    Saber que algo falla antes que el cliente

    Registra los errores del navegador y de las funciones donde los mires, con alertas para lo grave, sin datos personales en los logs.

    En Calma: los errores del navegador se guardan con un tope por usuaria y por ventana de tiempo, y se ven en paneles de Grafana.

14. Cumplimiento

    Textos legales, RGPD y AI Act

    Una empresa con web necesita aviso legal (LSSI, art. 10). Con datos personales, política de privacidad y registro de tratamientos, con los proveedores que los procesan y si salen de la UE; con datos de salud, también una evaluación de impacto. Si la app usa IA, clasifica su riesgo según el AI Act, avisa cuando la persona interactúa con una IA (art. 50, desde el 2 de agosto de 2026) y deja escrito qué hace el modelo y quién decide.

    En Calma: tenemos privacidad, términos, registro de tratamientos, evaluación de impacto y un documento de AI Act que explica por qué no es de alto riesgo: la IA sólo propone y nada entra en el calendario sin que la usuaria lo acepte.

15. Cumplimiento

    Si vas a App Store o Google Play, sus requisitos

    Una web se puede empaquetar como app con Capacitor, pero las tiendas piden más: borrar la cuenta desde la propia app, la ficha de privacidad de Apple y la sección de seguridad de los datos de Google Play coherentes con tu política, inicio de sesión que funcione en el móvil y una revisión que puede rechazarte. Trátalo como un proyecto en sí mismo.

    En Calma: los builds de iOS y Android salen solos cuando cambia la parte nativa, y la parte web llega a las apps instaladas con cada despliegue, sin pasar por la revisión de las tiendas.

Por dónde empezar si no tienes tiempo para todo

Por los puntos 1 a 4: son los que pueden exponer hoy los datos de tus clientes. Después, el 6 (copias) y el 9 (topes de coste), los dos sustos más caros. El resto se puede ir haciendo fase a fase, como en el Método AIHacks.

Preguntas frecuentes

¿Es segura una app hecha con Lovable?

Puede serlo, pero no por defecto. Lovable genera bien la interfaz y el flujo; la seguridad depende de las políticas de la base de datos, de dónde estén las claves y de lo que compruebe el servidor. Hay que revisarlo antes de tener clientes reales.

¿Qué es RLS y por qué importa tanto en Supabase?

Row Level Security es la regla de Postgres que decide qué filas puede leer o cambiar cada usuario. En Supabase el navegador consulta la base directamente con una clave pública, así que RLS es la única barrera entre un usuario y los datos de los demás.

¿Es un problema que la clave anon de Supabase esté en el frontend?

No, si RLS está bien: la clave anon o publishable está pensada para ir en el navegador. Lo grave es cualquier otra: la service_role, que se salta RLS, o las de OpenAI, Gemini, Stripe o el correo, que sólo pueden estar en el servidor.

¿Tengo que cumplir el AI Act si mi app sólo llama a una API de IA?

Sí, en lo que te toque: tú despliegas el sistema aunque el modelo sea de otro. Hay que clasificar su riesgo, avisar cuando la persona interactúa con una IA o ve contenido generado (art. 50, desde el 2 de agosto de 2026) y dejarlo documentado. La mayoría de apps no son de alto riesgo.

¿Puedo hacer esta revisión yo o necesito una auditoría?

Buena parte de la lista la puedes comprobar tú con las consultas y pasos de cada punto. Una auditoría tiene sentido cuando la app guarda datos personales, cobra a clientes o vas a publicarla en las tiendas, y quieres un informe de riesgos priorizado de alguien que no la ha construido.