una plataforma que crece contigo, no una que toca rehacer al año.
construimos plataformas web y saas que escalan de 10 a 10,000 usuarios sin reescribirse: cuentas, roles, suscripciones recurrentes y tableros en vivo, todo bajo tu propia marca. pensamos primero la base (quién entra, qué ve, cómo se cobra) y luego las funciones — por eso no se atora cuando llega el cliente grande. multi-tenant real con row-level security en Postgres (un bug no expone datos de otro cliente), sesiones httpOnly en vez de JWT en localStorage, billing con Stripe + dashboards sobre vistas materializadas (de 8s a 200ms).
contexto del problema.
Una plataforma SaaS bien construida tiene tres propiedades que las plataformas malas no: arquitectura multi-tenant correcta desde día uno, observabilidad granular para entender qué hace cada usuario, y un modelo de billing que no requiere abrir un Excel cada mes para conciliar. Las tres cosas son técnicas pero su efecto es de negocio: la primera te deja vender a empresas grandes con confianza (cada cliente tiene sus datos aislados a nivel de DB, no por filtro de aplicación). La segunda te deja descubrir qué features mover, descontinuar, vender por más caro. La tercera te deja escalar de 10 a 1,000 cuentas sin contratar a nadie de operaciones. Después de construir varias plataformas SaaS para clientes mexicanos en sectores tan distintos como salud (12 clínicas activas), educación online (cursos con asistente IA), ventas a crédito (cobranza automatizada por WhatsApp), el patrón es: la diferencia entre un SaaS que escala y uno que se atora está en las decisiones técnicas de los primeros 3 sprints. Por eso lo construimos en orden: primero auth + multi-tenancy + billing, después features de producto.
señales de que necesitas esto.
cómo lo construimos.
multi-tenancy: row-level security en postgres
Cada tabla tiene `tenant_id`. Cada sesión tiene un `JWT` o session cookie con el `tenant_id` del usuario. Postgres Row-Level Security (RLS) inyecta automáticamente `WHERE tenant_id = current_user_tenant()` en cada query. Esto significa: aunque tu código tenga un bug y olvide filtrar, Postgres NO devuelve data del tenant equivocado. Auditoría a nivel de DB, no de aplicación.
auth con sesiones, no con jwt en localStorage
Sesiones server-side con cookies httpOnly + SameSite=Lax. JWTs solo para APIs externas. Auth providers: Auth.js (NextAuth), Clerk, Supabase Auth — según preferencia y necesidades. Soporte para OAuth (Google, Microsoft), magic links, MFA con TOTP, y SSO/SAML para clientes empresariales.
billing: stripe billing + propio sistema de tiers
Stripe Billing como pasarela y sistema de prorations. En la DB local mantenemos espejo de subscriptions con webhooks. Sistema propio de tiers (Starter/Pro/Enterprise) con feature flags por tier. Dunning automático para pagos fallidos. Cambios de plan en self-service.
dashboards rápidos con vistas materializadas
Para dashboards con métricas agregadas (revenue por mes, usuarios activos, etc), usamos Postgres Materialized Views refrescadas cada 15 min o vía webhook. El dashboard hace UN query a una vista pre-calculada en lugar de 40 queries en vivo. Carga de 8s a 200ms.
observabilidad: posthog + sentry + db de eventos propia
PostHog para autocaptura de clicks + funnels + retention cohorts. Sentry para errores con sourcemaps. DB propia de eventos críticos (eventos que afectan billing, eventos auditables) para tener acceso SQL directo. Logs estructurados en JSON.
alcance típico.
stack típico.
rangos de inversión.
Cotización por proyecto con precio cerrado · sin comisiones recurrentes · CFDI 4.0. Estos son rangos típicos de proyectos en esta disciplina, basados en alcance promedio. Cada propuesta se cotiza individual.
Para detalle completo de tiers, términos de pago y política de cambios, ver la página de precios.
casos en producción.
preguntas frecuentes.
- ¿La diferencia técnica entre web app, plataforma y SaaS?
- Web app: aplicación accesible desde el navegador con auth (ej: una herramienta interna). Plataforma: web app que conecta a múltiples partes (ej: marketplace, social network). SaaS: web app o plataforma que se vende como suscripción a múltiples clientes/empresas (multi-tenant). Construyamos las 3 con el mismo stack base, pero las decisiones de arquitectura cambian.
- ¿Multi-tenancy schema-per-tenant o row-per-tenant?
- Row-per-tenant con Postgres Row-Level Security para 90% de los casos. Es más simple, escala bien hasta miles de tenants, y el aislamiento es real (no aplicación). Schema-per-tenant solo cuando hay requisitos regulatorios extremos (banca, salud con auditoría externa) — y aún ahí hay que pesarlo contra el costo operativo.
- ¿Construyen apps con compliance NOM-024 (salud)?
- Sí, hemos construido EHR / expediente clínico electrónico bajo NOM-024. Eso requiere: firma electrónica avanzada en cada consulta, audit log inmutable, separación estricta de datos sensibles, retención según ley, certificación. Auditoría externa la pasamos en primer intento con Cofre Médico.
- ¿Cómo manejan los pagos recurrentes en MXN?
- Stripe Billing si tu mercado es internacional (cobra en MXN, USD, EUR, etc.). Mercado Pago Subscriptions si tu mercado es 100% mexicano y quieres conversión más alta + MSI. Para enterprise grandes, soportamos invoicing manual con facturación CFDI 4.0 mensual.
- ¿Y si quiero exportar mis datos del SaaS algún día?
- Tu DB es tuya. La hosteamos donde decidas (tu cuenta de AWS/Supabase si prefieres) o en la nuestra con backup mensual a tu storage. API completa para extracción. Te entregamos schema documentado. Sin lock-in técnico.
- ¿Soportan SSO/SAML para clientes enterprise?
- Sí, vía Auth.js + librerías SAML, o vía proveedor (WorkOS, Auth0). Lo implementamos cuando llega el primer cliente que lo pide — generalmente al cruzar 50+ usuarios por tenant.
- ¿Cuánto tarda una plataforma de cero a producción?
- MVP funcional con auth + 3 features core: 6-10 sem. SaaS multi-tenant con billing + dashboards + roles + integraciones: 3-6 meses. Plataforma compleja con marketplace + payouts + mobile app: 6-12 meses. Cada hito tiene fecha y hay staging visible desde el primer sprint.
- ¿Cómo escalan cuando el tráfico crece de 100 a 10,000 usuarios?
- Frontend: Vercel escala horizontal automáticamente, sin intervención. Backend: serverless functions o Fargate/ECS con auto-scaling. DB: Postgres con read replicas + connection pooling (PgBouncer). Caching: Redis. Lo dimensionamos en arquitectura inicial, no como retrofit.
hablemos del tuyo.
30 min de llamada gratis o llena el formulario · respondemos en menos de 24 h hábiles con preguntas concretas o un rango de precio cerrado.