Un patrón que se repite: una empresa construye un sistema para resolver su propio problema, funciona muy bien, y otras empresas de la industria preguntan si se lo pueden usar. Ahí aparece la palabra “multi-tenant”.
La idea en una frase
Un SaaS multi-tenant es una sola aplicación que usan muchas empresas (los “tenants” o inquilinos), donde cada una ve y administra solo sus propios datos, usuarios y configuración. Es como un edificio: todos comparten estructura, ascensores y mantención, pero cada departamento tiene su propia llave.
Por qué no simplemente copiar el sistema para cada cliente
Se puede instalar una copia separada por cliente, y a veces tiene sentido (clientes muy grandes o con exigencias de aislamiento total). Pero con decenas de clientes se vuelve inmanejable: cada mejora hay que desplegarla en cada copia, cada error hay que corregirlo en cada una y los costos de infraestructura se multiplican. El modelo multi-tenant tiene una sola versión que mejora para todos a la vez.
Lo que un SaaS multi-tenant necesita
Aislamiento de datos
Es lo más importante. Un cliente nunca debe poder ver datos de otro, ni por error de programación. Las formas habituales:
- Base de datos compartida con reglas por fila: cada registro tiene el identificador del cliente y la base de datos impide leer lo que no te corresponde (por ejemplo, con Row Level Security en PostgreSQL).
- Un esquema por cliente dentro de la misma base.
- Una base por cliente, para los que lo exigen.
La elección depende del número de clientes, de la sensibilidad de los datos y de las exigencias contractuales.
Usuarios, roles e invitaciones
Cada empresa cliente debe poder invitar a su gente, asignar roles y revocar accesos sin pedírtelo a ti.
Suscripciones y cobro
Planes, períodos de prueba, cobro recurrente y qué pasa cuando un pago falla. En Chile y la región se usan pasarelas como Stripe o Flow.
Configuración por cliente
Nombre, logo, parámetros propios, módulos activos. Lo justo para que cada cliente sienta el sistema como suyo, sin crear versiones distintas del código.
Operación
Monitoreo, respaldos, ambientes separados de prueba y producción, y una forma de desplegar mejoras sin interrumpir a nadie.
Cuándo lo necesitas
- Ya resuelves un problema para varios clientes y lo haces a mano o con copias del sistema.
- Tu sistema interno le sirve a otras empresas de tu industria.
- Quieres cobrar una suscripción en vez de proyectos.
Si solo tienes un cliente (tú), no lo necesitas todavía. Pero si piensas venderlo, conviene diseñar la base pensando en eso desde el principio: agregar aislamiento después es mucho más caro.
Un caso real
Exovita es nuestro SaaS para el cumplimiento normativo SAG de criaderos. Cada criadero administra sus planteles, resoluciones y declaraciones sobre la misma plataforma, con sus datos aislados del resto. Lo construimos con Next.js, TypeScript, tRPC y Supabase en un monorepo.
¿Tienes un sistema que otros quieren usar? Cuéntanos qué resuelve y te decimos qué haría falta para convertirlo en producto.