Por qué un SaaS se hace multiempresa desde la primera línea

Es una de las preguntas más frecuentes al empezar un SaaS: construir primero para el cliente que ya está, y abrirlo a los demás cuando el producto funcione. Suena razonable y tiene un costo que conviene conocer antes de decidir.

Qué significa multiempresa

Un sistema multiempresa atiende a varias empresas cliente sobre la misma instalación, y cada una ve solo sus datos. Es lo que separa un SaaS de un software a medida, que se instala una vez por cliente.

La palabra que se usa en la industria es multi-tenant, y describe algo más concreto de lo que parece: cada consulta a la base de datos tiene que saber de qué empresa es quien está preguntando, y ninguna puede devolver una fila que no le corresponde.

Por qué no se puede agregar después

Porque no es una funcionalidad: es una condición que atraviesa todo lo construido.

La base de datos. Cada tabla que guarda información de un cliente necesita saber a qué empresa pertenece cada fila. Agregarlo después significa modificar todas esas tablas y migrar los datos existentes decidiendo, uno por uno, a quién pertenecen.

Cada consulta. Toda lectura tiene que filtrar por empresa. Un sistema hecho para una sola no lleva ese filtro en ninguna parte, así que hay que revisarlas todas. Y la que se olvide no va a fallar: va a devolver datos de otro cliente, que es la peor forma de fallar que existe.

Los permisos. Deja de bastar con saber qué puede hacer una persona. Hay que saber también en qué empresa está, porque el mismo correo puede pertenecer a dos. Eso cambia cómo se inicia sesión y cómo se invita a alguien.

Todo lo que se configura. Precios, plantillas de correo, campos propios, logotipo. En un sistema para una empresa esas cosas son constantes; en uno multiempresa son datos, y cada uno de esos cambios toca las pantallas donde se usan.

Los archivos. Dónde se guardan y quién puede descargarlos. Una URL de archivo que no valida a qué empresa pertenece es una filtración esperando a que alguien pruebe cambiar un número.

Qué cuesta rehacerlo

Depende de cuánto se haya construido, y ahí está el problema: crece con el tiempo. Sobre un producto que lleva unos meses en producción, agregar multiempresa suele significar rehacer buena parte de la capa de datos, revisar todas las consultas y migrar lo que ya existe sin perder nada ni mezclar información entre clientes.

Es trabajo que no agrega una sola funcionalidad visible. Quien lo paga no ve nada nuevo en pantalla al terminar, que es lo que hace difícil justificarlo cuando ya hay clientes esperando otras cosas.

Hacerlo desde el principio también cuesta, pero mucho menos: es diseñar la misma base de datos con una columna más y escribir las consultas con el filtro puesto desde la primera. La diferencia entre las dos opciones no está en el esfuerzo total sino en cuándo se paga.

Cuándo sí conviene empezar por uno solo

No siempre hay que construir multiempresa. Conviene no hacerlo cuando el producto todavía es una apuesta y el primer cliente es quien la financia: si existe una posibilidad real de que el producto no siga, pagar por una arquitectura que sostiene a cien clientes es pagar por algo que no se va a usar.

En ese caso lo honesto es decirlo: esto se está construyendo para una empresa, y abrirlo a más va a costar rehacer una parte. Con esa frase escrita en la propuesta, la decisión la toma quien paga y no aparece como sorpresa dieciocho meses después.

Lo que no funciona es lo intermedio: construir para uno solo mientras se promete que después escala. Eso no es una decisión, es una cuenta pendiente.

Qué preguntar en una propuesta

Si estás cotizando un SaaS, estas tres preguntas separan una propuesta que lo pensó de una que no:

1. ¿El sistema va a ser multiempresa desde la primera versión, sí o no?
2. Si no, ¿qué habría que rehacer para agregarlo y cuándo conviene hacerlo?
3. ¿Cómo se garantiza que una empresa no pueda ver datos de otra, y cómo se prueba eso?

La tercera es la que más dice. Separar datos es fácil de afirmar y difícil de demostrar, y quien lo ha hecho antes tiene una respuesta concreta. Es una de las cosas que conviene mirar al elegir con quién desarrollar, y una de las que mueven cuánto cuesta un SaaS.