Orden de UtzilOn
Cómo está organizado el SaaS: clientes, accesos, apps y las reglas que mantienen un solo código para N clientes.
Qué es
UtzilOn es el SaaS: el sistema sobre el que corre todo.
Clientes
Cada cliente = un schema en la DB + un realm de identidad aislado + su propio dominio.
Hada — el cliente interno (dogfooding)
UtzilOn administrándose a sí mismo. En la DB es el schema utzilon; lo llamamos “Hada” (por Ada Lovelace) solo para no confundirlo con el SaaS. Es quien administra las apps y da de alta las nuevas.
Externos: Vigotski · Flux Capital · DRM y Asociados · Sincrolink · La Terraza.
La tríada de acceso
Siempre bajo el dominio del cliente:
app.{dominio} Uso diario. El usuario entra aquí y hace todo lo que la app permite.
accounts.{dominio} Identidad del usuario: sus datos, organizaciones y accesos.
console.{dominio} Administración de la organización: membresías, facturación, APIs conectadas. Lo que casi no se toca. Solo para los owners que ese cliente definió.
El console es siempre por-dominio del cliente y aislado por realm/org (RLS). Nunca un panel central compartido. Un owner de Vigotski entra a console.vigotski.app, jamás ve utzilon.com ni datos de otro cliente. (El único console.utzilon.com es el de Hada, porque Hada es la org Utzilon.)
API
Vive en core.utzilon.com — central, multi-tenant; resuelve el cliente por host/JWT. Es backend, no entra en la tríada de usuario. (Hoy corre en otro lado por legacy → migra a core.utzilon.com.)
Apps
Corren en app.{app}.utzilon.com, su landing en {app}.utzilon.com (QA: {app}.ebers.mx).
| Producto | Qué hace |
|---|---|
| Utzil Alux | Rastreo GPS de flotillas |
| Utzil Amate | Facturación electrónica 4.0 |
| Utzil Bej | Links cortos y analítica |
| Utzil Hobnil | Control de acceso |
| Utzil Janal | Punto de venta para comida |
| Utzil Kanan | Gestión escolar |
| Utzil Konol | E-commerce |
| Utzil Kuxtal | Gestión para clínicas |
| Utzil Chultún | Gestión de inventarios |
Ejemplo — Hada (dogfooding), app Amate
amate.utzilon.comlandingapp.amate.utzilon.comusoaccounts.utzilon.comcuentaconsole.utzilon.comadmin
Ejemplos — clientes
- Vigotski ·
app.vigotski.app·accounts.vigotski.app·console.vigotski.app - Flux Capital ·
app.fluxcapital.mx·accounts.fluxcapital.mx·console.fluxcapital.mx
Cómo compra un cliente
El cliente compra las apps que necesita. Son las mismas apps —brandeadas y/o combinadas— nunca forks. Cada cliente guarda en su schema las variantes por datos de sus productos, sin tocar el código original.
Variante por datos
Esto es lo que mantiene un solo código para N clientes — el seguro de vida del SaaS.
✅ Sí es variante
Vive como dato/config en el schema del cliente:
- Branding
- Módulos activos
- Campos y catálogos
- Flujos config-driven
- Combinación de apps
❌ No es variante
No se expresa por config:
- Ramas de lógica de negocio core por cliente
- Si un cliente necesita comportamiento que no se expresa por config → es un módulo/app nuevo, no una “variante”