Hostelería01 / 12
Enigma
Una plataforma de operativa de restaurantes, varios locales bajo una misma cuenta
- Estado
- En desarrollo
- Periodo
- 2026 →
- Rol
- Diseño y desarrollo, de principio a fin
- Para
- Grupos de restauración independientes con más de un local.
Plano · 2D
La sala en directo desde arriba: cada mesa con su número y su estado, planta por planta.
Cómo funciona la asignación (simulación)Un modelo interactivo de la idea: ábrelo para probarlo.
Simulación — ilustra la idea; no es el motor de producción.
Asignación de mesas, paso a paso
- Libre
- Ocupada para esta petición
- Asignada
Resultado
Elige comensales, hora y zona, y pide una mesa.
Ocupación
Problema
Los restaurantes trabajan con un mosaico de herramientas para reservas, sala, personal y facturación, y cada una conoce solo una parte del servicio. Reglas como la normativa laboral o los alérgenos acaban en la cabeza de las personas.
Enigma gestiona la operativa diaria de restaurantes: reservas, asignación de mesas, turnos del personal, pagos, facturación, fidelización, pedidos y una tienda. Nació como la web de un restaurante en Calpe, España, y creció hasta ser una plataforma pensada para convertirse en SaaS multi-tenant.
Caso de estudio
La plataforma cubre una cuenta con varios locales. Las reservas y la disponibilidad pasan por motores de asignación que deciden qué mesa encaja con qué grupo y cuándo. La planificación del personal aplica reglas laborales, y los pagos, la facturación (Veri*factu) y los pases de wallet conviven con la fidelización y los pedidos.
Es un workspace de nueve aplicaciones (API, asistente, consola, carta, equipo, terminal, tienda, web y worker) sobre unos cuarenta y cinco paquetes compartidos. El objetivo es una única base que más adelante sirva a muchos negocios de restauración sin reescribirla.
Arquitectura
Toda operación pasa por un único despachador de kernel. La separación en capas de paquetes la impone dependency-cruiser, la autenticación es un servidor OAuth 2.1 con JWT firmados con EdDSA y un endpoint JWKS, y los permisos son RBAC dirigido por el servidor con exclusiones por local. El stack corre en Docker Compose con Postgres, Caddy, Gotenberg y un Cloudflare Tunnel, y expone superficies MCP.
Decisiones técnicas
- Un despachador como punto de paso obligado, para aplicar auditoría, permisos y reglas en un solo sitio.
- Los límites entre capas los comprueban las herramientas, no la costumbre.
- RBAC dirigido por el servidor con exclusiones por local, para que una cuenta pueda tener muchos locales con seguridad.
- Construido primero para una cuenta, con el modelo de datos preparado para SaaS multi-tenant.
Retos y compromisos
Mantener coherentes nueve aplicaciones y decenas de paquetes mientras cambian las reglas de un restaurante real. El despachador y las capas impuestas existen para que ese crecimiento sea seguro.
Resultados verificados
- ≈2.070 commits
- ~1.950 archivos de test
- 9 aplicaciones y ~45 paquetes en un workspace
Los estados son factuales: nada se presenta más terminado de lo que está.