Alle Projekte

Offline-first POS für die Gastronomie

Eine Mobile-first POS-Plattform für kleine Unternehmen in Gastronomie und Einzelhandel. Läuft standardmäßig offline und ist in mehreren Ländern fiskalkonform.

Jahr
2024 - present
Stack
KotlinVueNodeExpressPostgreSQLSQLitePrismaStripe
OF
Offline-first POS für die Gastronomie

Das Problem

Die meisten POS-Systeme, die an kleine Unternehmen verkauft werden, teilen sich ein paar bekannte Schwächen. Sie verlangen ein Web-Dashboard, um alles Wichtige zu verwalten, was einen Laptop im Backoffice voraussetzt, nicht das Telefon in der Hosentasche. Sie zwingen den Betreiber an den hauseigenen Payment-Processor des Anbieters. Sie verlangen Premium-Preise und binden diese an lange Verträge. Sie kommen mit kaputten oder fehlenden Funktionen (Inventar, das nicht abgleicht, Berichte, die nicht aufgehen). Und fast immer brauchen sie eine Internetverbindung, um ihren eigentlichen Job zu erledigen: Zahlungen entgegenzunehmen.

Für den kleinen Betreiber, ein Café, eine Bar, einen Friseursalon, einen kleinen Laden, sind das echte Kosten. Eine abgebrochene WLAN-Verbindung wird zum verlorenen Verkauf. Eine Preisänderung verlangt den Weg nach Hause an den Laptop. Die Bindung an einen Payment-Processor wird zur dauerhaften Steuer auf jede Transaktion.

Dieses Produkt wurde gebaut, um genau das zu lösen, für kleine Unternehmen, die sich Reibung an der Kasse nicht leisten können.

Der Ansatz

Das Produkt baut auf drei bewussten Entscheidungen auf: Mobile-first-Verwaltung, Offline-first-Betrieb und freie Wahl des Payment-Processors.

Native Android für Kasse und Verwaltung. Die Kasse und das Verwaltungs-Dashboard leben in derselben nativen Kotlin-App. Betreiber können eine Kasse betreiben, Inventar verwalten, Preise anpassen, Analytics ansehen und Personal einarbeiten, alles vom Telefon aus, mitten im Betrieb, zwischen den Kunden. Das Web-Dashboard existiert als optionaler Zusatz für Schreibtischarbeit, nicht als Abhängigkeit.

Offline-first by Design. Die Kasse funktioniert ohne Internetverbindung. Die Einrichtung braucht Konnektivität: ein Admin meldet sich an, weist ein Gerät einer Kasse zu, und das Gerät zieht alles, was es braucht, Produkte, Preise, Steuern, Tische, Personal, Fiskalkonfiguration. Danach läuft das Gerät unbegrenzt offline. Belege, Verkäufe, Lagerbewegungen werden lokal in SQLite (via Room) gespeichert und synchronisieren sich mit dem Server, sobald die Verbindung wieder da ist.

Die Sync-Schicht ist der unspektakuläre Engineering-Kern des Produkts. Sie löst Konflikte zwischen Geräten, kommt mit Fiskalregeln zurecht, die verzögerte Fiskalisierung erlauben (Kroatien verlangt, dass jeder Beleg "so schnell wie möglich" fiskalisiert wird, eine nicht-triviale Bedingung), und verwaltet die Grenze zwischen Online-wenn-möglich und Offline-wenn-nötig, ohne Daten zu verlieren oder doppelt zu schreiben.

Freie Wahl des Payment-Processors. Die meisten POS-Anbieter zwingen ihren Kartenprozessor auf. Dieses System integriert Stripe, Square, Teya und SumUp out of the box, mit weiteren in der Roadmap. Betreiber behalten ihre bestehenden Beziehungen zu Banken und Anbietern.

Multi-Location und Multi-Country, per Architektur. Filialen, Lager, Kassen und Inventar bilden die reale Hierarchie ab. Ein Unternehmen kann mehrere Filialen betreiben, jede mit eigenem Lager und eigenen Kassen. Inventar wird auf Lagerebene geführt. Die fiskalische Konformität ist pro Land austauschbar, aktuell unterstützt sind das kroatische und das britische Fiskalregime. Neue Regionen kommen als Fiskal-Module dazu, nicht als Re-Architektur.

Der kroatische Fiskalisierungs-Flow wurde bewusst zuerst gebaut. Das kroatische Fiskalrecht zählt zu den strengsten überhaupt: jeder Beleg muss kryptografisch signiert, an die Steuerbehörde übermittelt und abgeglichen werden, inklusive offline aufgelaufener Belege. Sobald Kroatien gelöst war, ging das Hinzufügen von UK (ein einfacheres Regime) reibungslos. Die Architektur kehrt die übliche Fiskal-Schmerzkurve um.

Das Ergebnis

Die Plattform ist in der finalen QA mit fünf Pilot-Betreibern aus Gastronomie und Einzelhandel. Unterstützt werden zwei Länder (Kroatien, UK), wobei die Multi-Country-Architektur auf dem schwierigeren Fall zuerst bewiesen wurde. Die App läuft seit drei Monaten im Pilot ohne einen einzigen Absturz. Das Onboarding ist ein zweistufiger Prozess in der App, ohne Vertriebsanruf.

Die erste Vertriebspartnerschaft ist in Vorbereitung, mit einem Partner, der vorhat, seinen eigenen Betrieb auf derselben Plattform zu führen. Dieses Vertrauenssignal nehmen wir vor jeder Marketing-Seite.

Als nächstes: öffentlicher Launch, Erweiterung der fiskalischen Abdeckung auf weitere EU-Regionen und Einführung der geplanten Payment-Processor-Anbindungen.

Nächstes Projekt

Voice-AI-Agent für Enterprise-Telefonie

Case Study lesen