La arquitectura central: separación de responsabilidades
El mayor error en los SaaS no-code es usar una plataforma todo-en-uno (Bubble, Glide) donde frontend y backend están fuertemente acoplados. Esto causa tres problemas a escala: el rendimiento se degrada porque no puedes escalar frontend y backend de forma independiente, tus datos quedan bloqueados en la plataforma, y no puedes optimizar cada capa por separado.
La arquitectura correcta separa las responsabilidades: - Frontend: WeWeb (entregado por CDN, escalable de forma independiente) - Lógica de negocio: Xano (API escalable horizontalmente) - Base de datos: Supabase (PostgreSQL gestionado, escala a miles de millones de filas) - Automatización: Make o n8n (trabajos asíncronos, webhooks, notificaciones)
Esta es la misma separación que usan los equipos técnicos que construyen SaaS en AWS o GCP, pero con herramientas no-code en lugar de código personalizado. Para SaaS B2B en España y LATAM que apuntan a clientes enterprise, esta arquitectura también es un argumento sólido en auditorías de seguridad: cada capa puede ser revisada y validada de forma independiente, y los datos se almacenan en PostgreSQL estándar sin bloqueo propietario.
La capa de base de datos: PostgreSQL con RLS
Tu modelo de datos es la decisión arquitectónica más importante. Hazlo bien y escalar es sencillo. Hazlo mal y tendrás que reconstruir.
Principios clave para una base de datos SaaS no-code escalable: 1. Cada tabla tiene created_at, updated_at y una clave primaria (bigserial) 2. Multi-tenant mediante clave foránea workspace_id en cada tabla 3. Políticas de Row-Level Security en cada tabla que acceda el usuario 4. Índices en workspace_id, user_id, status, created_at 5. Nunca almacenes valores calculados en la base de datos, calcúlalos en Xano
Supabase PostgreSQL maneja esto excelentemente. Las políticas RLS significan que tus endpoints de API no pueden devolver accidentalmente datos de otro tenant, la base de datos garantiza el aislamiento. Desde la perspectiva del RGPD y Schrems II, esto es un argumento poderoso para clientes B2B en España: el control de acceso a datos está garantizado a nivel de base de datos, no solo a nivel de aplicación.
Los límites borrosos en el modelo de datos son la causa más común de reconstrucciones. Invierte tiempo en modelar tus datos correctamente antes de construir un solo endpoint de API.
La capa de API: lógica de negocio en Xano
Xano se sitúa entre tu frontend y la base de datos. Cada acción del usuario pasa por un endpoint de Xano, no directamente a Supabase. Eso te da: - Validación de entradas antes de tocar la base de datos - Lógica de negocio (cálculos de precios, máquinas de estado, comprobaciones de permisos) - Integraciones de terceros (Stripe, SendGrid, Twilio) en un solo lugar - Registro de auditoría a nivel de API
Estructura tus endpoints de Xano de forma RESTful: GET /workspaces/:id/projects, POST /projects, PATCH /projects/:id. Evita endpoints estilo RPC. Mantén los endpoints pequeños y componibles.
Un patrón que usamos consistentemente: crear funciones "utility" en Xano por servicio externo, por ejemplo "Cobrar con Stripe" o "Enviar email de bienvenida via Brevo". Luego llama a estas utilities desde tu stack de lógica de negocio. Para SaaS en España y LATAM, las integraciones comunes incluyen Stripe (pagos), Brevo/SendGrid (email), MercadoPago o Conekta (LATAM), y Holded o Quaderno (facturación con IVA).
La capa de frontend: rendimiento con WeWeb
WeWeb genera una app web real: HTML/CSS/JS estático entregado via CDN, con datos dinámicos obtenidos mediante llamadas API REST. Eso significa: - La primera carga es rápida (activos estáticos cacheados en CDN) - Los datos se cargan de forma asíncrona (sin cuello de botella de renderizado en servidor) - El frontend escala infinitamente (son solo archivos en un CDN)
Para rendimiento a escala: pagina todas las consultas de lista (máximo 50 elementos por página), usa el caché integrado de WeWeb para datos estáticos y carga de forma perezosa componentes pesados.
Una ventaja subestimada: WeWeb genera HTML real, lo que significa que tus páginas de marketing y páginas públicas se indexan correctamente en Google. Para SaaS en España y LATAM que dependen del SEO para adquisición de clientes, una estrategia común donde los precios de publicidad son altos, esta es una ventaja decisiva frente a Bubble, cuyos Lighthouse scores en móvil típicamente aterrizan en 40-55.
Autenticación y multi-tenancy
Usa Supabase Auth para la autenticación de usuarios, está battle-tested y es gratuito en el nivel Free. El flujo: 1. El usuario se registra/inicia sesión via Supabase Auth 2. Supabase emite un JWT con user_id y workspace_id 3. WeWeb almacena el JWT, lo envía con cada solicitud de API a Xano 4. Xano valida el JWT y extrae el contexto del usuario 5. Las políticas RLS de la base de datos usan auth.uid() para aplicar aislamiento a nivel de fila
Para multi-tenancy: crea una tabla workspaces, una tabla workspace_members (user_id, workspace_id, rol) y envía workspace_id con cada solicitud de API. Xano verifica la membresía antes de cada operación.
No olvides manejar los casos extremos: ¿qué pasa si un usuario es miembro de múltiples workspaces? ¿Cómo manejas las invitaciones por email? Estos patrones están bien documentados, no los reinventes. Supabase tiene documentación oficial para patrones multi-tenant con RLS que cubre los escenarios más comunes.
¿Cuándo migrar a código personalizado?
Esta arquitectura escala cómodamente a 100.000 MAU para la mayoría de tipos de SaaS. Más allá de eso, pueden aparecer cuellos de botella específicos:
- Flujo de escritura muy alto (> 1.000 escrituras/segundo): Supabase PostgreSQL gestionado puede necesitar compute dedicado - Funciones en tiempo real complejas (multijugador, colaboración en vivo): puede que quieras infraestructura WebSocket personalizada - Inferencia LLM personalizada: los modelos auto-alojados requieren infraestructura personalizada
Para el 95% de los productos SaaS, esta arquitectura es más que suficiente a cualquier escala. Y cuando necesites migrar una capa, puedes hacerlo, tus datos están en PostgreSQL estándar, tu API es REST, tu código frontend es tuyo.
Este es un argumento importante para SaaS en España o LATAM que planean captar inversión de fondos de VC. La arquitectura no tiene bloqueo propietario, cada capa puede ser reemplazada de forma independiente, y los datos pueden exportarse a cualquier base de datos relacional sin conversión.