La stack central
Frontend: WeWebUI perfecta al píxel, se conecta a cualquier backend, desplegado en tu propio dominio via CDN de Cloudflare.
Base de datos + Auth: SupabasePostgreSQL, Row-Level Security, suscripciones en tiempo real, almacenamiento de archivos.
Lógica de negocio + API: Xanoconstructor de API REST, lógica de negocio personalizada, integraciones de terceros, webhooks.
Pagos: Stripesuscripciones, facturas, webhooks de vuelta a Xano.
Email: Resend o SendGridemails transaccionales disparados por Xano.
Esta stack maneja 10.000 MAU sin esfuerzo. La hemos ejecutado a 50.000 MAU sin cambios de infraestructura. Para SaaS en España con precios en EUR o en LATAM con precios en USD/MXN/ARS, Stripe soporta múltiples divisas y gestión automática de impuestos (IVA en España, IVA en México).
Multi-tenancy con Supabase RLS
Cada tabla tiene una columna workspace_id. Todas las políticas de Row-Level Security filtran por workspace_id = auth.jwt() ->> 'workspace_id'.
Los usuarios pertenecen a workspaces a través de una tabla workspace_members con una columna de rol (owner, admin, member). Cuando un usuario inicia sesión, su JWT contiene su workspace_id y rolSupabase lo aplica automáticamente a nivel de base de datos.
Esta es la decisión arquitectónica más importante en un SaaS B2B. Hazla bien desde el día 1. Hemos visto empresas que omitieron esto en la fase de validación y luego necesitaron una migración completa de base de datos cuando consiguieron sus primeros clientes empresaun proceso costoso que App Studio puede ayudarte a evitar si nos contactas antes de empezar a construir.
Arquitectura de facturación con Stripe
En Xano creas un endpoint de webhooks que recibe eventos de Stripe. Gestiona: checkout.session.completed (crear registro de suscripción), customer.subscription.updated (actualizar plan), invoice.payment_failed (restringir acceso).
Almacena el estado de suscripción en una tabla workspace_settings. En WeWeb, comprueba el estado de suscripción antes de renderizar características premiumy en las políticas RLS de Supabase para restricciones de datos.
Nunca confíes en el frontend para las compuertas de facturación. Verifica siempre en la base de datos. Para clientes en España que pagan en EUR, Stripe gestiona automáticamente el IVA del 21 %. En México, Stripe maneja el IVA del 16 % y puede generar facturas CFDI a través de integraciones de terceros.
Optimización del rendimiento
Estrategia de índices: indexa cada clave foránea, cada columna de estado/tipo usada en filtros y cada columna por la que ordenas. En Supabase esto lleva 2 minutos en el editor SQL.
Paginación: todos los endpoints de lista deben paginar. Nunca devuelvas consultas sin límite. Usa paginación basada en cursor para datos en tiempo real (scroll infinito) y offset para tablas de administración.
Caché: Xano soporta caché de respuestas para endpoints que devuelven los mismos datos para todos los usuarios (contenido público, tablas de consulta). Úsalo agresivamente. Un endpoint de Xano bien cacheado puede manejar miles de llamadas por segundo sin estresar Supabase.
Monitoreo y gestión de errores
Añade Sentry en tu código personalizado de WeWeb para errores de frontend. Xano registra todas las solicitudes APIexpórtalos a Datadog o usa el monitoreo de errores integrado de Xano.
Para trabajos en background críticos (webhooks de facturación, disparadores de email), añade notificaciones de error a Slack via Make. Deberías saber de los errores antes que tus usuarios.
Monitoreo de base de datos: Supabase proporciona insights sobre rendimiento de consultas. Revisa las consultas lentas semanalmente. Una causa común de degradación del rendimiento en empresas en crecimiento son consultas que funcionan bien con 100 filas pero son catastróficamente lentas con 100.000la indexación temprana elimina este problema.
Patrones de multi-tenancy: bases de datos compartidas frente a aisladas
Existen tres modelos de multi-tenancy: base de datos compartida con RLS (todos los tenants en las mismas tablas, aislados mediante políticas), base de datos compartida con esquemas separados (cada tenant tiene su propio esquema de PostgreSQL) y bases de datos separadas por tenant. La inmensa mayoría de las apps SaaS con 10.000 usuarios o menos deberían usar el primer modelo, base de datos compartida con RLS. Es el más sencillo de construir, el más barato de operar, y el RLS de Supabase lo hace genuinamente seguro.
Los esquemas separados por tenant (a menudo llamado "schema-per-tenant") se vuelven relevantes cuando los tenants tienen estructuras de datos legítimamente distintas, algo poco frecuente en la práctica. Las bases de datos separadas por tenant son una característica de nivel enterprise que se usa cuando los tenants requieren garantías contractuales de residencia de datos o sus propias credenciales de base de datos. En App Studio implementamos el modelo de base de datos compartida con RLS para todos los productos SaaS, hasta que un cliente tiene un requisito contractual específico de aislamiento más estricto.
El detalle de implementación crítico: cada INSERT debe fijar workspace_id explícitamente, y tus políticas RLS WITH CHECK deben exigir que workspace_id coincida con el workspace del usuario autenticado. Si te lo saltas en un solo endpoint, un usuario podría insertar datos en el workspace de otro tenant. Validamos esto con una batería de pruebas de seguridad que crea dos workspaces de prueba y verifica el aislamiento de datos en los más de 50 endpoints.
Principios de diseño de base de datos para SaaS no-code
El esquema de base de datos es la base sobre la que descansa todo lo demás. Decisiones de esquema deficientes en el mes 1 provocan problemas en cascada en el mes 12. El principio más importante: diseña para tus consultas, no para una normalización teórica. Si siempre vas a consultar los proyectos junto con su workspace y su propietario asociados, guarda workspace_id y owner_id directamente en la tabla projects en lugar de hacer join con workspace_members cada vez.
Usa restricciones a nivel de base de datos como una segunda capa de validación. Claves foráneas (project.workspace_id referencia a workspaces.id), restricciones not-null en los campos obligatorios y restricciones check para valores tipo enum (status IN ('active', 'paused', 'cancelled')). Estas restricciones detectan errores de tu capa de aplicación antes de que corrompan tus datos. Supabase las aplica de forma nativa: añádelas cuando creas tus tablas, no como una idea de última hora.
Para la facturación de un SaaS, usa una tabla subscription dedicada en lugar de guardar los datos del plan directamente en la tabla workspace. Una suscripción tiene un ciclo de vida (trialing, active, past_due, cancelled) con marcas de tiempo para cada transición de estado. Guardarlo como una entidad separada mantiene limpia la lógica de facturación y te da un registro de auditoría completo, esencial para resolver disputas de facturación y depurar anomalías de ingresos.
Estrategia de caché: qué cachear y dónde
El caché en una stack SaaS no-code funciona en tres niveles: caché de endpoints en Xano (a nivel de respuesta), vistas materializadas en Supabase (a nivel de consulta) y estado del lado del cliente en WeWeb (a nivel de UI). Cada uno cumple un propósito distinto y tiene requisitos de invalidación diferentes.
El caché de endpoints en Xano es apropiado para datos que son iguales para todos los usuarios y cambian poco: tablas de consulta (listas de países, categorías de sector), planes de precios públicos, configuraciones de feature flags. Fija un TTL de entre 5 y 60 minutos según la frecuencia con la que cambien los datos. Esto reduce significativamente la carga de la base de datos en los endpoints que se llaman en cada carga de página.
Las vistas materializadas de Supabase son la herramienta adecuada para consultas de agregación costosas: métricas de uso a nivel de workspace, datos de informes mensuales, cálculos de leaderboard. Refréscalas según una programación (cada 15 minutos para dashboards casi en tiempo real, una vez al día para informes de facturación) usando la extensión cron de Supabase. Hemos reducido el tiempo de carga del dashboard 10 veces en apps SaaS con mucha analítica moviendo las agregaciones a vistas materializadas.
El caché del lado del cliente en WeWeb, a través de su almacén de variables integrado, reduce las llamadas API redundantes dentro de una misma sesión. Cachea la configuración del workspace, el estado de la suscripción y los feature flags del usuario actual al iniciar sesión: se necesitan en cada página y no cambian a mitad de sesión. Invalida el caché al cerrar sesión y al actualizar de plan.
Trabajos en background: patrones para procesamiento asíncrono
Cualquier operación que tarde más de 500 ms debería ser asíncrona. En una stack SaaS no-code, los trabajos en background se ejecutan en la cola de tareas de Xano, activados mediante programadores de Make.com o n8n, o mediante Edge Functions de Supabase activadas por cambios en la base de datos.
Los trabajos en background más habituales en los productos SaaS que construimos son: procesamiento de renovación de suscripciones (comprobar todos los workspaces con renovación prevista hoy, cobrar en Stripe, actualizar el estado de la suscripción, enviar el email de recibo), generación de exportaciones de datos (el usuario solicita una exportación CSV, el job la genera y envía por email un enlace de descarga, nunca bloquees la UI para esto), sincronización con terceros (enviar nuevos contactos del CRM a HubSpot, sincronizar eventos de calendario con Google Calendar) y medición de uso (agregar cada hora las llamadas API o el uso de funcionalidades para la facturación).
La gestión de errores en los trabajos en background requiere más cuidado que en los endpoints síncronos: no hay un usuario esperando una respuesta. Cada job debería: registrar su inicio y su fin, capturar todos los errores y escribirlos en una tabla job_errors, enviar una alerta a Slack ante los fallos, e implementar una lógica de reintento con backoff exponencial para fallos transitorios (errores de red, límites de tasa). La cola de tareas de Xano gestiona los reintentos de forma nativa; para los jobs activados desde Make.com, implementa la lógica de reintento en el propio escenario.
Monitorizar un SaaS no-code en producción
La monitorización en producción sin un equipo de DevOps requiere elegir las herramientas adecuadas y automatizar las alertas. Para la stack que usamos, la configuración mínima viable de monitorización es: Sentry para errores de frontend (integración en el código personalizado de WeWeb), los logs de peticiones integrados de Xano con alertas de error, los insights de rendimiento de base de datos y monitorización del connection pool de Supabase, y el dashboard de Stripe para las tasas de fallo de pago.
Más allá de la monitorización de errores, haz seguimiento de métricas de salud a nivel de negocio: usuarios activos diarios (consulta a Supabase), distribución del tiempo de respuesta de la API (exporta los logs de Xano), intentos de login fallidos (posibles eventos de seguridad) y tasa de cancelación de suscripciones (webhooks de Stripe → Supabase → una vista de reporting sencilla). Configura informes semanales automatizados que envíen estas métricas por email al fundador: la mayoría de los problemas se hacen visibles como cambios de tendencia antes de convertirse en crisis.
Para apps SaaS por encima de 5.000 MAU, añade monitorización de uptime vía Better Uptime o Pingdom en tus endpoints críticos (login, flujo principal). Alerta a Slack en menos de 2 minutos tras una caída. Con este volumen de usuarios, incluso una caída de 10 minutos en horario laboral genera un volumen de soporte considerable. El coste de la monitorización de uptime (20-50 euros al mes) está sobradamente justificado.