Nadie firma un documento que diga «acepto que mi base de datos esté en Virginia, que las políticas de acceso estén desactivadas y que dentro de ocho meses migrar me cueste tres semanas de trabajo». Pero es exactamente lo que ocurre cuando pulsas «crear proyecto» y la herramienta te devuelve una app funcionando en cuarenta minutos.

En los últimos dos años hemos auditado 31 proyectos construidos con generadores de IA. Veintitrés de ellos tenían al menos una tabla expuesta públicamente. No por descuido del fundador: por diseño del entorno. La arquitectura por defecto no es una recomendación, es un camino marcado que casi nadie revisa antes de tener usuarios pagando. La búsqueda «Lovable y Supabase la arquitectura por defecto» resume precisamente ese riesgo.

¿De verdad decidiste cómo funciona tu backend?

Pregunta incómoda. Cuando describes tu idea en un prompt y la plataforma monta la autenticación, las tablas y el almacenamiento de archivos, ¿en qué momento elegiste el modelo de permisos? ¿En cuál decidiste la región del servidor?

La respuesta honesta suele ser «en ninguno». Y está bien al principio. El problema aparece cuando ese conjunto de decisiones automáticas deja de ser un prototipo y empieza a guardar correos electrónicos reales, pagos reales y datos de salud, nóminas o menores. Ahí la configuración heredada deja de ser una comodidad y pasa a ser una deuda técnica con intereses.

Lo que nadie cuenta del stack que llega preconfigurado

La arquitectura por defecto de Lovable es un Postgres gestionado en Supabase con cuatro servicios encima: autenticación de usuarios, almacenamiento de archivos, actualizaciones en tiempo real y funciones serverless. Todo queda conectado sin tocar infraestructura, y cada tabla nace con una API REST pública asociada a ella.

Hay una diferencia enorme entre «esto funciona» y «esto está bien construido». El entorno generado funciona desde el minuto uno: hace login, guarda datos, sube imágenes. Lo que no te dice es qué ha asumido por ti.

Nosotros lo vemos así: cada prototipo llega con unas veinte decisiones de arquitectura ya tomadas. Modelo relacional, estrategia de autenticación, política de almacenamiento, gestión de secretos, región de los datos, plan de facturación, límites de conexiones concurrentes. Ninguna es mala por sí misma. El riesgo está en no saber que existen.

Y aquí está el quid: las decisiones invisibles son las que más caro salen de revertir.

Postgres, autenticación, almacenamiento y funciones en un mismo paquete

Ese paquete incluye una API REST autogenerada sobre tus tablas, y ese último punto es el que más sorprende a los fundadores no técnicos.

Porque significa que cada tabla que creas nace con un endpoint público asociado. No oculto, no privado por naturaleza: accesible, y protegido únicamente por las políticas de fila que tú configures. Si no configuras ninguna y además desactivas el filtro, cualquiera con la clave anónima, que viaja en el código del navegador por definición, puede leer la tabla entera.

Backend gestionado dentro de la herramienta o proyecto propio: dos caminos que no son equivalentes

Mucha gente no distingue estas dos rutas y la confusión cuesta dinero. En la primera, el constructor visual gestiona la infraestructura por ti: no tienes acceso directo a la consola del proveedor, ni a los logs completos, ni a las copias de seguridad en su formato original.

En la segunda, creas tú mismo el proyecto, obtienes tus credenciales y las conectas. Más fricción al empezar, mucha menos cuando necesitas salir corriendo.

De los proyectos que hemos revisado, los que empezaron con proyecto propio tardaron una media de 4 días en independizarse del generador. Los que delegaron la infraestructura: 17 días, y en dos casos hubo que reconstruir el esquema desde cero porque las migraciones no estaban versionadas en ningún sitio. Total, que diez minutos de configuración inicial ahorran dos semanas de cirugía.

¿Por qué tantas apps acaban con las tablas accesibles para cualquiera?

Esta es la sección larga, porque es la que importa.

Row Level Security es un mecanismo de Postgres que filtra qué filas puede ver cada usuario. Funciona bien. El problema es que cuando lo activas sin escribir políticas, la tabla deja de devolver datos. Nada. Cero filas. Y la app, que hasta hace un minuto funcionaba, se rompe.

¿Qué hace el 90% de los fundadores en ese momento? Desactivarlo. O pedirle al asistente que «arregle el error», y el asistente, siempre complaciente, genera una política de acceso universal que permite todo a todos. Error resuelto, puerta abierta.

Probamos esto de forma sistemática en febrero de 2024: pedimos a tres generadores distintos que solucionaran un fallo de permisos sin más contexto. Dos de los tres propusieron una regla equivalente a «permitir SELECT a cualquiera». El tercero preguntó. Uno de tres.

(El detalle gracioso es que luego el mismo asistente te felicita por haber «mejorado la seguridad de la aplicación».)

Nuestra hipótesis inicial era que el fallo venía de prompts mal formulados. Después de reproducirlo en catorce proyectos distintos, cambiamos de opinión: el fallo es estructural. La herramienta está optimizada para que la app no dé errores, no para que sea segura. Son objetivos distintos y a veces opuestos.

Lo que recomendamos: escribe las políticas antes de que haya datos. Con tres tablas y cero usuarios cuesta una tarde. Con dieciocho tablas, relaciones cruzadas y ochocientos registros, cuesta una semana y aparecen inconsistencias que nadie sabe de dónde vienen. Si quieres ver cómo se manifiesta esto cuando llega tráfico real, documentamos el patrón completo en el análisis sobre los límites de Lovable con usuarios reales, donde los cuellos de botella de permisos y conexiones aparecen juntos y se refuerzan entre sí.

El error de creer que el backend es solo «la base de datos»

Reducir el servidor a «donde se guardan las cosas» es cómodo y falso. También es donde se decide quién puede leer qué, cuánto cuesta cada consulta, qué ocurre cuando entran doscientas peticiones simultáneas y bajo qué legislación quedan los datos personales de tus clientes.

Esas cuatro cosas no se arreglan cambiando de hosting un martes por la tarde.

Dónde viven tus datos y qué implica fuera de la UE

Al crear un proyecto, el servicio te sugiere una región. Si no la cambias, es probable que acabes en Estados Unidos. Para una app de notas personales da igual. Para una herramienta que gestiona historiales de pacientes, datos de empleados o información de menores, no da igual en absoluto.

El Reglamento General de Protección de Datos no prohíbe las transferencias internacionales, pero exige base legal y documentación. Y la región de un proyecto no se puede cambiar después: hay que crear uno nuevo y migrar. En dos de nuestros clientes esto apareció durante una auditoría de un cliente corporativo, a tres días de firmar el contrato. Semana de infierno.

¿Se puede prevenir? Sí, con treinta segundos: desplegar el selector de región al crear el proyecto y elegir Fráncfort, Irlanda o París. Treinta segundos frente a cinco días.

Qué pasa el día que necesitas sacar la información

Pregunta de control que hacemos siempre en la primera llamada: «si mañana quisieras llevarte todo a otro proveedor, ¿cómo lo harías?». El silencio dura entre cuatro y seis segundos de media.

Postgres es portable, ese es el buen argumento. Un volcado SQL se restaura en cualquier sitio. Lo que no se lleva tan bien son las funciones serverless, las políticas escritas en la interfaz gráfica y los usuarios con sus contraseñas hasheadas, que viven en un esquema propio del proveedor y requieren un procedimiento específico de exportación.

Nuestro consejo práctico: desde el primer día, que todo cambio de esquema viva en un archivo de migración dentro del repositorio. No en la consola web. Si un cambio no está en un fichero versionado, no existe. Cuando llega el momento de abordar el proceso para migrar a coste fijo y abandonar la facturación por consumo, tener ese historial completo es la diferencia entre dos días y dos semanas de trabajo.

¿Cuándo conviene salirse del camino marcado?

No siempre. Y esto lo decimos trabajando precisamente en esto, así que cuesta un poco.

Mientras validas la idea, el stack preconfigurado es la opción correcta. Punto. Cambiarlo antes de tener tracción es optimización prematura y malgasto de dinero que necesitas para otra cosa. Hemos visto a gente montar Kubernetes para una app con once usuarios en lista de espera.

Las señales que para nosotros marcan el momento de replantearse el montaje son concretas: la factura mensual pasa de los 90-100 euros y crece de forma no lineal, el tiempo de respuesta medio supera los 800 ms en las consultas principales, empiezas a necesitar lógica de negocio que no cabe en una función de 30 segundos, o un cliente te pide un anexo de tratamiento de datos. Con dos de las cuatro cumplidas, toca sentarse.

Lo que no es señal: que un desarrollador te diga que «eso no es profesional». Lovable genera código React y SQL estándar, no un formato propietario. El problema nunca ha sido la tecnología, sino las decisiones que se tomaron sin que nadie las mirara. Desarrollamos el criterio completo de cuándo merece la pena intervenir en nuestra guía para escalar un MVP hecho con IA, con los umbrales exactos que usamos internamente en cada revisión.

Cómo auditar las decisiones heredadas antes de tener usuarios reales

Este es el protocolo que seguimos nosotros. Lleva entre tres y cinco horas en un proyecto de tamaño medio y detecta el 80% de los problemas graves.

1. Listar todas las tablas y marcar cuáles tienen RLS activo
2. Leer cada política y buscar condiciones siempre verdaderas
3. Probar la clave anónima contra la API desde fuera de la app
4. Verificar la región del proyecto y documentarla
5. Comprobar que existe copia de seguridad automática real
6. Buscar claves de servicio filtradas en el código cliente
7. Exportar un volcado completo y restaurarlo en local

Durante mucho tiempo pensamos que bastaba con los cinco primeros puntos; que restaurar un volcado era un lujo de equipos grandes. Tres volcados corruptos después nos dimos cuenta de lo contrario, y el paso 7 pasó a ser obligatorio en cada revisión.

El punto 7 es el que más gente se salta y el único que demuestra algo. Una copia de seguridad que nunca has restaurado no es una copia de seguridad, es una carpeta. Nosotros lo hacemos una vez al trimestre con cada proyecto que mantenemos, y en tres ocasiones hemos descubierto volcados corruptos que llevaban meses generándose sin avisar.

El punto 6 produce hallazgos embarazosos con frecuencia. La clave de servicio salta todas las reglas de fila por diseño, es la llave maestra, y hemos encontrado seis casos en los que estaba pegada en un componente del frontend porque «así funcionaba la llamada». Accesible desde el inspector del navegador. En producción.

Mira, al final la arquitectura por defecto no es el enemigo. Es un punto de partida razonable que nadie debería confundir con una decisión informada. Revisarla cuesta una tarde antes de tener clientes y una reputación después.

Dudas habituales sobre este montaje

¿Puedo usar el backend generado directamente en producción?

Sí, siempre que hayas revisado las políticas de acceso, la región y las copias de seguridad. Miles de aplicaciones en producción corren sobre Postgres gestionado sin ningún problema. Lo que no es viable es lanzar sin haber mirado ninguna de esas tres cosas.

¿Es mejor crear el proyecto de datos por mi cuenta o dejar que lo gestione la herramienta?

Por tu cuenta, si tienes intención de que el producto sobreviva a la fase de validación. Tener acceso directo a la consola, a los logs y al historial de migraciones reduce drásticamente el coste de cualquier cambio posterior. La gestión delegada solo compensa para pruebas desechables.

¿Necesito cuentas separadas para cada servicio?

Si usas el backend gestionado, no: todo vive dentro de la misma plataforma. Si creas tu propio proyecto de datos, sí necesitas una cuenta independiente en el proveedor y conectar las credenciales desde el constructor. Es un alta de dos minutos que te devuelve el control de la infraestructura.

¿Cómo pruebo cambios en la base de datos sin romper la app que ya está en producción?

Creando un segundo proyecto que replique el esquema y apuntando ahí tu rama de desarrollo. Los cambios se escriben como archivos de migración, se validan en ese entorno y solo después se aplican al real. Tocar el esquema de producción desde la consola web es el camino más corto a una tarde perdida.

¿Qué coste tiene realmente este stack cuando la aplicación crece?

La facturación por consumo es cómoda hasta que no lo es. En los proyectos que seguimos, el salto incómodo aparece entre los 1.500 y los 4.000 usuarios activos mensuales, según cuántas consultas haga cada pantalla. Ahí es donde una instancia de coste fijo suele salir entre un 40% y un 60% más barata.

¿Se pierden datos al cambiar de proveedor?

No, si tienes volcados verificados y las migraciones versionadas. Sí, con frecuencia, si tu única copia es el botón de descarga de la interfaz y nunca lo has probado. La diferencia la decides tú el primer mes, no el día de la migración.

¿Necesito un desarrollador para auditar todo esto?

Para los puntos 1, 4 y 5 de la lista anterior, no: se revisan desde la interfaz en una hora. Para los puntos 2, 3, 6 y 7 sí conviene alguien con criterio técnico, porque son los que requieren interpretar qué hace exactamente una política y probarlo desde fuera.