Zentrale technische Fallstudie
SyncPlate
Eine mandantenfähige POS-Plattform für Restaurantbetrieb, Stripe-Zahlungsterminals, SUNMI-Hardware, Belegdruck und deutsche Fiskalabläufe — ergänzt um Warenbestand, Personal und HACCP.
- Rolle
- Creator, Product Owner und Full-Stack-Entwickler
- Aktueller Status
- In aktiver Entwicklung · Gestartet im Mai 2024
Überblick
Überblick
Eine mandantenfähige Gastronomie-Plattform mit 14 Laravel-Fachmodulen, isolierten Mandantendatenbanken und einer Expo-Codebasis für Web, Android, iOS, Stripe-Zahlungsterminals und SUNMI-POS-Geräte. Terminal-Pairing, Gerätestatus, Belegdruck, TSE und Zigbee-/MQTT-Sensorik gehören zum selben operativen System.
Geschäftliches Problem
Ein Restaurant steuert Bestellungen, Personal, Bestand, POS-Hardware, Zahlungsterminals und steuerliche Pflichten gleichzeitig — in Deutschland zusätzlich signierte Belege, unveränderliche Audit-Trails und DSFinV-K-Exporte. Schwierig ist nicht die Anzahl der Funktionen, sondern jeden Mandanten isoliert, jeden Fiskalsatz nachweisbar und jeden Geräteablauf vorhersehbar zu halten, während mehrere Personen und Geräte im laufenden Betrieb denselben Zustand ändern.
Mein Beitrag
- Eine mandantenfähige Laravel-12-Plattform mit 14 Fachmodulen, zentraler Routing-Datenbank und isolierter Datenbank je Mandant entwickelt und getestet.
- Bestell-, Verkaufs-, Bestands-, Fiskal-, HACCP- und IoT-Abläufe in Anforderungen für ein Redis-Streams-Backbone mit Transactional Outbox und idempotenten Consumern übersetzt.
- Deutsche Fiskalanforderungen recherchiert und auf Provider-Capabilities für fiskaly-TSE-Signierung, DSFinV-K-Export, Tagesabschluss und hash-verketteten GoBD-Audit-Log abgebildet.
- Operative Analyse- und Prognoseabläufe für Verkauf, Bestand, Beschaffung, Produktion, Menu Engineering und Trends umgesetzt.
- Den Sensorablauf von Zigbee über MQTT zur API einschließlich laufender HACCP-Telemetrie und Gerätekopplung im Admin-UI gesteuert und validiert.
- Eine Expo-Codebasis für Web, Android, iOS und dedizierte Terminals koordiniert und validiert — einschließlich Stripe Terminal, Geräte-Pairing und -status sowie drei praktisch getesteten Thermodrucker-Transportwegen.
Praxisnahe Geräteintegration
POS, Payment & Hardware
Praktische Entwicklung, Integration und Tests von Kassenhardware — von Stripe-Zahlungsterminals und SUNMI-Android-POS-Geräten über ESC/POS-Belegdruck und QZ Tray bis zu fiskaly TSE. Dazu gehören Geräte-Pairing, Statusüberwachung, Druckerkommunikation und die Diagnose von Verbindungs- und Integrationsfehlern.
Technische Herausforderungen
Technische Herausforderungen
Mandantentrennung ohne Fork je Kunde
Eine zentrale Routing-Datenbank ermittelt den Mandanten, danach läuft der Request gegen dessen eigene Datenbank. Eine Codebasis, keine geteilten Datensätze, kein Weg für Cross-Tenant-Zugriffe.
Events, die einen Absturz überstehen
Domain-Events werden in derselben Transaktion geschrieben wie die auslösenden Daten und danach an Redis Streams übergeben. Consumer führen einen Idempotenz-Speicher, sodass ein Replay keinen Umsatz doppelt zählt.
Steuerrecht als austauschbarer Treiber
Deutschland verlangt fiskaly-TSE-Signierung, DSFinV-K, Tagesabschluss und nachvollziehbare Audit-Logs. Provider deklarieren ihre Fähigkeiten über Contracts; hash-verkettete Einträge sichern die GoBD-bezogene Auditierbarkeit, ohne die Fachlogik an einen Anbieter zu binden.
Prognosen, die eigene Fehler eingestehen
Bedarfsprognose ist mehr als ein Modellaufruf: Der Dienst backtestet gegen die Historie, korrigiert Bias und überwacht den eigenen Fehler — mit Wetter und Feiertagen als Merkmalen.
Vom Sensor in die Datenbank, unbeaufsichtigt
Zigbee-Temperatursensoren senden über MQTT an eine Python-Bridge, die die Telemetrie an die API weiterreicht; neue Hardware wird aus der Admin-Oberfläche gekoppelt statt über die Shell.
Eine Codebasis, vier sehr verschiedene Ziele
Web, Android, iOS und dedizierte Zahlungsterminals teilen sich eine Expo-Codebasis. Capability-Prüfungen kapseln Stripe Terminal, SUNMI-Druck, Bluetooth-ESC/POS und QZ Tray; Pairing-, Verbindungs- und Druckfehler lassen sich dadurch gezielt diagnostizieren.
Plattformkarte
Wofür das Backend tatsächlich zuständig ist.
14 Module in einer Laravel-Codebasis, benannt wie im aktuellen Verzeichnis app/Modules und nach ihrer Aufgabe gruppiert.
Service & Gastraum
4 Module
- OrderBons, Gänge, Teilrechnungen
- TableTischplan und Live-Belegung
- OnlineOrderingAußer Haus in dieselbe Warteschlange
- DlvLieferaufträge und Disposition
Ware & Produktion
4 Module
- CatalogKarte, Artikel, Varianten
- InventoryBestände, Inventur, Gebinde
- ProcurementLieferanten und Bestellwesen
- DiscountPreisregeln und Aktionen
Geld & Recht
4 Module
- CashKassenverantwortung je Schicht
- AccountingBuchhaltungsexporte
- AuditLogHash-verketteter GoBD-Trail
- BillingWas jeder Mandant zahlt
Plattform
2 Module
- SettingsKonfiguration je Mandant
- SuperAdminMandantenverwaltung
Geräte
POS-, Payment- und Druckhardware im System.
Die Integrationen werden an realen Geräteabläufen geprüft: Konfiguration, Pairing, Online-/Offline-Status, Druckerkommunikation und Fehlerdiagnose. Jede Geräteklasse liegt hinter einer Capability-Prüfung — die Kasse bleibt auch ohne optionale Hardware funktionsfähig.
Stripe Terminal & SUNMI POS Devices
Praktische Integration und Tests physischer Zahlungsterminals und Android-POS-Hardware — mit Pairing, Verbindungsstatus, Payment Flow und gerätespezifischen Funktionen innerhalb des Kassensystems.

Stripe Reader S700
Stripe Terminal
Die Kasse am Tresen. Der Expo-Client läuft auf dem Leser selbst — Bestellung und Kartenzahlung passieren auf einem Bildschirm, statt zwei Geräte synchron halten zu müssen.

BBPOS WisePOS E
Stripe Terminal
Der Leser, der auf dem Tresen bleibt. Er gehört zur festen Kasse und nicht zu einer Person — die Station ist einsatzbereit, wer auch immer davorsteht.

SUNMI POS Devices
SUNMI SDK · Android POS
Praktische Entwicklung und Tests auf SUNMI V3H und SUNMI T2 Mini S — einschließlich integriertem Thermodrucker, SUNMI SDK und gerätespezifischen POS-Funktionen.

BBPOS WisePad 3
Stripe Terminal
Ein Bluetooth-PIN-Pad, gekoppelt an Smartphone oder Tablet — um am Tisch zu kassieren, ohne dieser Station einen eigenen Smart Reader zu geben.

Tap to Pay
Phone as reader
Gar kein Leser — das Smartphone in der Schürze ist das Kontaktlos-Terminal. Der günstigste Weg, für einen vollen Abend eine zweite Kasse zu öffnen.
Nichts davon ist Voraussetzung für den Einsatz des Systems. Ein Betrieb, der bereits ein Kartenterminal seiner Bank hat, behält es und ändert nichts: Die Kasse bucht den Verkauf als Kartenzahlung, und die Bedienung bestätigt ihn, sobald das eigenständige Terminal die Zahlung als erfolgreich meldet. Nichts zu migrieren, kein Vertrag zu kündigen. Ein integrierter Leser spart genau diesen einen Tastendruck — er schaltet den Bezahlvorgang nicht erst frei.
Thermodrucker & ESC/POS
Integration und Tests von Bondruckern über Netzwerk/LAN mit ESC/POS und QZ Tray, über Bluetooth ESC/POS sowie gerätespezifisch über das SUNMI SDK. Der Client wählt den passenden Druckweg zur Laufzeit pro Gerät.

Countertop thermal printer
Network ESC/POS · QZ Tray
Belege an der Kasse — und derselbe Transportweg noch einmal für Küchen- und Bardrucker. Ein Küchenbon ist ein Beleg, der für einen anderen Leser gedruckt wird.

Mobile thermal printer
Bluetooth ESC/POS
Wird am Gürtel zum Handgerät getragen — ein gedruckter Beleg am Tisch bedeutet damit nicht den Rückweg zum Tresen.
Bildschirme für andere
Alle bisherigen Geräte richten sich an die Person, die aufnimmt. Diese drei richten sich an Küche und Gast — deshalb werden sie mit nassen Händen bedient oder gar nicht berührt.

Wired bump bar
Kitchen display
Einen Bon abschließen ist ein Tastendruck. Wer mitten im Service kocht, hat nasse Hände und keine Aufmerksamkeit für ein Touch-Ziel übrig.

Wireless bump bar
Kitchen display
Dieselbe Steuerung für Pass oder Bar, wo sich kein Kabel zum Bildschirm verlegen lässt.

Customer display
Second screen
Die Gastseite des Tresens: laufende Bestellung und Summe, sichtbar bevor die Karte gezückt wird — nicht danach.
Herstellerrenderings und Beispielaufnahmen der unterstützten Geräteklassen, keine Fotos einer konkreten Installation.
Screenshots
Screenshots
Aufnahmen aus der laufenden Anwendung. Seriennummern, Netzwerkadressen und Sensorkennungen sind geschwärzt.
Architektur
Architektur
Die Laravel-API ermittelt den Mandantenkontext zentral und arbeitet danach gegen die isolierte Datenbank dieses Mandanten. Geschäftsereignisse nutzen eine Transactional Outbox und Redis Streams, das IoT-Gateway führt Zigbee-Sensoren über MQTT in dieselbe API, und eine Expo-Codebasis deckt Web, Android, iOS und dedizierte Terminals ab.
Ergebnis
Ergebnis
Eine funktionierende Plattform mit 14 Laravel-Fachmodulen, einem IoT-Gateway und einem plattformübergreifenden Client — vom Auftrag und der Zahlung über Warenbestand, Personal und HACCP bis zum Fiskalabschluss. Das Produkt befindet sich weiterhin in aktiver Entwicklung.



