Caso de estudio · Gran Mayorista
De software a la medida a SaaS multi-tenant en seis meses
Gran Mayorista empezó resolviendo el problema de un solo distribuidor. Cuando otros negocios del mismo sector lo pidieron, la decisión no fue vender copias del sistema: fue reescribir la base para que un solo despliegue sirviera a muchas empresas sin que sus datos se tocaran nunca.
- Rol
- Arquitectura, desarrollo, despliegue y soporte
- Periodo
- Diciembre 2025 – actualidad
- Estado
- En producción, más de 10 negocios
- Equipo
- Yo en tecnología, 2 socios en expansión comercial
El problema
La primera versión se construyó para un solo distribuidor mayorista: su catálogo, sus precios, sus empleados, su nómina. Funcionaba porque cada supuesto del negocio estaba incrustado en el código y en el esquema de datos.
En pocos meses aparecieron otros mayoristas pidiendo lo mismo. El camino corto —clonar el proyecto y desplegar una instancia por cliente— resuelve la primera venta y destruye la décima: cada corrección hay que aplicarla diez veces, cada base de datos evoluciona por su lado y el costo de soporte crece linealmente con los clientes.
El problema real no era agregar clientes. Era dejar de tener un sistema por cliente.
Antes · una instancia por cliente
Hoy · un despliegue, muchas empresas
Cada corrección se aplica N veces y cada base de datos evoluciona por su lado.
Sin contexto de empresa, la consulta falla: el aislamiento no depende de recordarlo.
Diagrama comparativo. A la izquierda, el modelo anterior: cada negocio tenía su propia copia de la aplicación y su propia base de datos, tres despliegues independientes. A la derecha, el modelo actual: los tres negocios entran a un único despliegue que consulta una sola base de datos, donde cada fila cuelga de un identificador de empresa.
Decisiones de arquitectura
Un solo despliegue, muchas empresas. Toda entidad del dominio pasó a colgar de un identificador de empresa, y el acceso a datos se cerró de forma que ninguna consulta pueda ejecutarse sin ese filtro. El aislamiento no depende de que el desarrollador se acuerde de aplicarlo: si falta el contexto de empresa, la consulta falla.
Roles y permisos por empresa, no globales. Un usuario existe dentro de una empresa y sus permisos se resuelven en ese ámbito, porque el dueño, el vendedor y el bodeguero ven cosas distintas del mismo sistema.
La facturación electrónica DIAN se construyó una sola vez, fuera del producto. En vez de integrar la normativa en cada sistema, hice un servicio compartido sobre la API de Factus del que consumen Gran Mayorista, AutomatIQ POS y Mechss. Factus permite que la empresa madre compre un paquete de documentos electrónicos y lo distribuya entre las empresas usuarias, lo que evita que cada negocio pequeño tenga que gestionar su propio proveedor.
El módulo DIAN es una pieza aparte del sistema principal. Fue una petición explícita de los usuarios, y coincide con la decisión técnica: mantiene el cumplimiento normativo desacoplado del núcleo de operación.
Resultado
Más de 10 negocios mayoristas operan hoy sobre un solo despliegue. Una corrección se despliega una vez y llega a todos.
Sumar un cliente nuevo dejó de ser un proyecto de infraestructura y pasó a ser un registro en el sistema.
La expansión comercial la llevan mis dos socios; yo sostengo la plataforma. Esa división es la razón por la que el crecimiento no está limitado por mi tiempo.
Lo que sigue
Terminar la facturación electrónica DIAN vía Factus y llevarla a los tres productos.
La visión de producto es una red entre los mayoristas asociados, para que los negocios que ya comparten la plataforma puedan comerciar entre ellos.
¿Quieres hablar sobre este trabajo o sobre una posición?
sebastianmunoz603@gmail.com