Hospitality01 / 12
Enigma
A restaurant operations platform for several venues under one account
- Status
- In development
- Period
- 2026 →
- Role
- Design and development, end to end
- For
- Independent restaurant groups that operate more than one venue.
Floor plan · 2D
The live room from above: every table, its number and its state, floor by floor.
How allocation works (simulation)An interactive model of the idea — open to try it.
Simulation — illustrates the idea; not the production engine.
Table allocation, step by step
- Free
- Busy for this request
- Allocated
Result
Choose a party size, time and zone, then request a table.
Occupancy
Problem
Restaurants run on a patchwork of tools for bookings, floor, staff and billing, and each one knows only a slice of the shift. Rules such as labour law or allergen handling end up living in people's heads.
Enigma runs the daily operations of restaurants: reservations, table allocation, staff scheduling, payments, invoicing, loyalty, ordering and a shop. It started as the website of a restaurant in Calpe, Spain, and grew into a platform meant to become multi-tenant SaaS.
Case study
The platform covers one account with several venues. Reservations and availability run through allocation engines that decide which table fits which party and when. Staff planning applies labour-law rules, and payments, invoicing (Veri*factu) and wallet passes sit next to loyalty and ordering.
It is a workspace of nine apps (API, assistant, console, menu, team, terminal, shop, web and worker) built on roughly forty-five shared packages. The aim is a single base that can later serve many restaurant businesses without a rewrite.
Architecture
Every operation passes through one kernel dispatcher. Package layering is enforced by dependency-cruiser, authentication is an OAuth 2.1 server with EdDSA-signed JWTs and a JWKS endpoint, and permissions are server-driven RBAC with venue-scoped deny overrides. The stack runs in Docker Compose with Postgres, Caddy, Gotenberg and a Cloudflare Tunnel, and exposes MCP surfaces.
Engineering decisions
- One dispatcher as the choke point, so auditing, permissions and rules are applied in a single place.
- Layer boundaries checked by tooling, not by convention.
- Server-driven RBAC with venue-scoped deny overrides, so one account can hold many venues safely.
- Built for one account first, with the data model kept ready for multi-tenant SaaS.
Challenges & trade-offs
Keeping nine apps and dozens of packages coherent while the rules of a real restaurant keep changing. The dispatcher and the enforced layering exist to make that growth safe.
Verified results
- ≈2,070 commits
- ~1,950 test files
- 9 apps and ~45 packages in one workspace
Status labels are factual: nothing here is presented as more finished than it is.