Gastronomie01 / 12
Enigma
Eine Plattform für den Restaurantbetrieb, mehrere Standorte unter einem Konto
- Status
- In Entwicklung
- Zeitraum
- 2026 →
- Rolle
- Konzeption und Entwicklung, von Anfang bis Ende
- Für
- Unabhängige Restaurantgruppen mit mehr als einem Standort.
Saalplan · 2D
Der Raum live von oben: jeder Tisch mit Nummer und Status, Etage für Etage.
So funktioniert die Zuteilung (Simulation)Ein interaktives Modell der Idee — zum Ausprobieren öffnen.
Simulation — zeigt die Idee, nicht die Produktions-Engine.
Tischvergabe, Schritt für Schritt
- Frei
- Für diese Anfrage belegt
- Vergeben
Ergebnis
Wähle Personenzahl, Uhrzeit und Bereich und frage dann einen Tisch an.
Belegung
Problem
Restaurants arbeiten mit einem Flickenteppich aus Werkzeugen für Buchung, Service, Personal und Abrechnung, und jedes kennt nur einen Ausschnitt der Schicht. Regeln wie Arbeitsrecht oder Allergenkennzeichnung stecken am Ende in den Köpfen.
Enigma steuert den Tagesbetrieb von Restaurants: Reservierungen, Tischzuteilung, Personaleinsatz, Zahlungen, Rechnungen, Treueprogramm, Bestellungen und einen Shop. Es begann als Website eines Restaurants in Calpe, Spanien, und wuchs zu einer Plattform, die später als Multi-Tenant-SaaS dienen soll.
Fallstudie
Die Plattform deckt ein Konto mit mehreren Standorten ab. Reservierungen und Verfügbarkeit laufen über Zuteilungs-Engines, die entscheiden, welcher Tisch zu welcher Gruppe passt und wann. Die Personalplanung wendet arbeitsrechtliche Regeln an, und Zahlungen, Rechnungsstellung (Veri*factu) und Wallet-Pässe stehen neben Treueprogramm und Bestellungen.
Es ist ein Workspace aus neun Apps (API, Assistent, Konsole, Speisekarte, Team, Terminal, Shop, Web und Worker) auf rund fünfundvierzig gemeinsamen Paketen. Ziel ist eine einzige Basis, die später viele Gastronomiebetriebe ohne Neuentwicklung bedienen kann.
Architektur
Jede Operation läuft über einen zentralen Kernel-Dispatcher. Die Paketschichtung erzwingt dependency-cruiser, die Authentifizierung ist ein OAuth-2.1-Server mit EdDSA-signierten JWTs und JWKS-Endpunkt, und Berechtigungen sind serverseitiges RBAC mit standortbezogenen Deny-Overrides. Der Stack läuft in Docker Compose mit Postgres, Caddy, Gotenberg und einem Cloudflare Tunnel und bietet MCP-Schnittstellen.
Technische Entscheidungen
- Ein Dispatcher als Engstelle, damit Protokollierung, Berechtigungen und Regeln an einer Stelle greifen.
- Schichtgrenzen werden vom Tooling geprüft, nicht per Konvention.
- Serverseitiges RBAC mit standortbezogenen Deny-Overrides, damit ein Konto sicher viele Standorte halten kann.
- Zuerst für ein Konto gebaut, das Datenmodell bleibt aber bereit für Multi-Tenant-SaaS.
Herausforderungen & Abwägungen
Neun Apps und Dutzende Pakete stimmig zu halten, während sich die Regeln eines echten Restaurants laufend ändern. Dispatcher und erzwungene Schichtung sorgen dafür, dass dieses Wachstum sicher bleibt.
Belegte Ergebnisse
- ≈2.070 Commits
- ~1.950 Testdateien
- 9 Apps und ~45 Pakete in einem Workspace
Die Status sind sachlich: Nichts wird fertiger dargestellt, als es ist.