Plataforma SaaS Multi-Tenant

El problema

La compañía necesitaba una plataforma SaaS desde cero capaz de servir a múltiples clientes (“tenants”) con configuraciones, marcas y datos completamente aislados. Las opciones existentes en el mercado eran demasiado generalistas o demasiado caras para el segmento objetivo. La decisión: construir.

El reto técnico no era solo “construir un SaaS” — era construirlo bien desde el primer commit, con la estructura suficiente para que el cliente número 100 no requiriera reescribir lo que sirvió para el primero.

Decisiones de arquitectura

Multi-tenancy con aislamiento por base de datos. Cada tenant tiene su propia base de datos. Más complejidad operativa, pero garantiza aislamiento real, simplifica el modelo de datos por tenant y deja la opción abierta de hospedar tenants en infraestructura dedicada cuando crezcan.

Dominios personalizados por cliente. El sistema soporta tanto subdominios (cliente.app.com) como dominios completos (app.cliente.com) por tenant, con renovación automática de certificados. Permite a cada cliente operar bajo su propia marca sin fricción.

Panel administrativo centralizado. Filament (Laravel) sobre la base maestra para operación interna: provisioning de tenants, métricas, soporte. Panel separado del producto end-user para no mezclar responsabilidades ni esquemas.

Stack monolítico modular. Laravel + Inertia + Vue 3 — un único deployable, pero con módulos bien separados. Resistir la tentación de microservicios prematuros: se introducen solo cuando el monolito empieza a doler, no antes.

Infraestructura en AWS con Docker y CI/CD trazable. Cada release tiene un commit, un build, un deploy registrado y un rollback disponible. Sin sorpresas en producción.

Construcción

El desarrollo se estructuró bajo Spec-Driven Development: cada feature mayor pasó por una spec aprobada antes de implementarse. Específicamente para el provisioning de tenants y el routing por dominio — ahí los errores cuestan dinero.

Se priorizaron:

• Migraciones por tenant automatizables y reversibles
• Observabilidad: logs estructurados, métricas de negocio, alertas que importan
• Backups y disaster recovery desde el día uno, no como afterthought
• Onboarding de devs nuevos: README real, scripts make que funcionan, ambiente local con docker compose up

Resultado

Plataforma operando en producción, sirviendo tenants de manera estable. Sistema preparado para crecer en número de clientes sin reescritura — el siguiente nivel de escala es operativo (más tenants), no arquitectónico (cambiar de stack).

El equipo técnico se mantiene pequeño y productivo gracias a la disciplina de specs y la observabilidad en su lugar. Las decisiones técnicas tomadas en 2022 siguen siendo correctas hoy.

Lo que aprendí

• Multi-tenancy con DB-por-tenant es más trabajo, pero menos dolor a largo plazo. Las alternativas (single-DB con tenant_id) parecen más simples al principio y se vuelven el problema central a los 2 años.
• Filament aceleró el panel admin masivamente. Un trabajo de 3 meses con admin custom se redujo a 3 semanas con Filament + customizaciones puntuales.
• Inertia es el sweet spot entre SPA puro y Laravel tradicional. Hot reload, SSR, sin necesidad de mantener una API REST aparte para el front propio.
• AWS no es necesariamente la respuesta correcta — pero cuando ya lo es, Docker + CI/CD bien hechos hacen que la complejidad sea manejable.