Ramen Joe begann als Restaurant in Lissabon. Heute sind es fünf Häuser, eine im App Store veröffentlichte iOS-App, eine bei Google Play veröffentlichte Android-App, ein Treueprogramm mit Apple Wallet und Google Wallet sowie ein Back-Office, das den Betrieb der Gruppe steuert. Alles auf einer einzigen Plattform.
Dieser Artikel erzählt, was diese Plattform gelöst hat, was es gekostet hat, sie zu bauen statt SaaS von der Stange zu kaufen, und wo die meisten Gastronomiegruppen sich irren, wenn sie das Gleiche versuchen.
Executive Summary
Eine Gastronomiegruppe mit mehr als zwei Standorten hat typischerweise drei technische Probleme, die am Anfang niemand richtig einschätzt. Fragmentierte Reservierungen pro Haus. Ein Treueprogramm, das dem Gast nicht zwischen den Filialen folgt. Betriebsdaten, die in lokalen Dateien und WhatsApp-Nachrichten leben.
Ramen Joe hat den Betrieb in einem einzigen System konsolidiert. Geteilte Reservierungen, einheitlicher Kundendatensatz, Treueprogramm, digitale Speisekarte, Personalverwaltung und zentrale Auswertung. Praktisch heißt das: Der Gast, der in Lissabon stempelt, sieht denselben Punktestand in Porto, während das Team fünf Häuser verwaltet — und neue Standorte hinzufügen kann — aus demselben Back-Office.
Diese Entscheidung ist nicht billig. Aber die Kosten, sie nicht zu treffen, tauchen später auf, getarnt als Churn, doppelte Arbeit im Team und Expansionsentscheidungen im Blindflug.
Das Geschäftsproblem
Wenn aus einem einzelnen Restaurant eine Gruppe wird, beginnt die Software, die für ein Haus gut funktionierte, zu brechen. Nicht weil sie schlecht ist. Sondern weil sie für einen Kontext entworfen wurde, der nicht mehr deiner ist.
Das klassische Symptom: Jeder Standort landet mit seinem eigenen Reservierungsmodul, oft an Google oder ein spezifisches SaaS-Tool angebunden. Die Treuekunden leben in einer Datenbank pro Haus, oder schlimmer, in einem Papierheft. Wenn du wissen willst, wie viele Stammgäste die Gruppe hat, gibt es keine Antwort. Nur Schätzungen.
Der kritische Punkt ist dieser. In einem einzelnen Haus ist der Betriebsleiter das CRM. Er kennt die Stammgäste, weiß, wer den hinteren Tisch bevorzugt, weiß, wer sonntags die Familie mitbringt. Bei fünf Häusern funktioniert dieses verteilte Gedächtnis nicht mehr. Und der Gast merkt es.
Warum das wichtig ist
Kundenbindung in der Gastronomie ist kein operatives Detail. Sie ist das Rückgrat des Modells. Die Akquisekosten eines neuen Gastes sind ein Vielfaches der Kosten, einen bestehenden Gast zurückzuholen. Das gilt in fast allen Branchen, und die Gastronomie ist keine Ausnahme.
Wenn dein Treueprogramm dem Gast nicht zwischen den Filialen folgt, behandelst du jeden Besuch, als wäre es der erste. Ist er nicht. Der Gast erinnert sich. Nur das System nicht.
Der zweite Blickwinkel ist operativ. Eine Gruppe mit fünf Häusern erzeugt genug Daten, um fundierte Geschäftsentscheidungen zu treffen. Welche Uhrzeiten füllen sich zuerst. Welche Wochentage brauchen Kampagnen. Welcher Standort hat die meisten No-Shows. Ohne einheitliche Plattform existieren diese Daten, aber niemand kann sie lesen.
Was die Plattform leistet
Die Architektur von Ramen Joe basiert auf drei Bausteinen, die miteinander sprechen. Ein Express-Backend mit relationaler Datenbank, ein öffentliches Next.js-Frontend für Endkunden und eine Reihe nativer Apps (iOS SwiftUI und Android), die die Web-Erfahrung im mobilen Kontext abbilden.
Die Entscheidung für native Apps statt PWA verdient eine Erklärung. Es ist keine technische Eitelkeit. Es war eine Produktentscheidung, motiviert durch drei konkrete Gründe.
- Apple Wallet und Google Wallet lassen sich in nativen Apps sauber integrieren — die Treuekarte wandert direkt in das Wallet des Telefons und erhält automatische Updates, wenn sich der Punktestand ändert.
- Push-Benachrichtigungen unter iOS haben Einschränkungen, die das Web nicht umgehen kann, ohne die Erfahrung zu beschädigen.
- Tap-to-Scan durch das Personal im Restaurant braucht eine Kamera mit schnellem Autofokus und nahezu null Latenz. Hier verliert das Web noch.
Reservierungen sind entkoppelt vom Kalender jedes Hauses. Wenn ein Gast in Lissabon reserviert, wird der Tisch nur in Lissabon blockiert. Aber der Gastdatensatz, die Historie, die Tischpräferenz — all das ist global.
Digitale Speisekarte und Expansion ohne technische Abhängigkeit
Die Plattform zentralisiert auch die digitale Speisekarte der fünf Standorte. Das Team pflegt Produkte, Informationen und die Konfiguration jedes Hauses im selben Back-Office und hält die Erfahrung auf der Website und in den Apps konsistent, ohne die Arbeit pro Kanal zu duplizieren.
Die Mehrstandort-Verwaltung wurde so gestaltet, dass die Expansion der Gruppe nicht von einem neuen technischen Eingriff abhängt. Das Team selbst kann einen Standort anlegen, Öffnungszeiten, Kontakte, Speisekarte, Tische, Reservierungsregeln und weitere Betriebseinstellungen festlegen.
Nach der Konfiguration steht das neue Haus auf der Website und in den mobilen Apps aus derselben Datenquelle zur Verfügung. Es ist nicht nötig, eine neue Version der Website oder der Apps zu entwickeln, nur um eine Einheit hinzuzufügen. Das senkt Kosten und Zeit zwischen der Expansionsentscheidung und dem Auftritt des neuen Standorts in den digitalen Kanälen.
Treue über Filialen hinweg: die Entscheidung, die alles ändert
Der häufigste Reibungspunkt in Gastronomiegruppen ist dieser. Jedes Haus will sein eigenes Programm. Jeder Betriebsleiter will seine treuen Gäste sehen. Und jede Marketingkampagne bleibt tendenziell an einem Standort hängen.
Ramen Joe hat sich für das Gegenteil entschieden. Ein einziges Programm, ein einziger Punkte-Wallet, ein einziger Gast. Das hat nicht triviale Buchhaltungsfolgen — wer „bezahlt“ den in Lissabon vergebenen und in Porto eingelösten Stempel? — aber es wird mit internen Verrechnungsregeln gelöst, nicht durch Zersplitterung des Systems.
Der Gast sollte darüber nicht nachdenken müssen. Und tut es auch nicht. Er installiert die App einmal, fügt die Karte ins Wallet ein, und die Erfahrung ist in jedem Haus der Gruppe dieselbe. Das ist Product-Market-Fit für Kundenbindung.
Die Rolle des Personals
Ein digitales Treueprogramm funktioniert nur, wenn das Personal mitzieht. Wenn der Stempelvorgang länger dauert als das alte Verfahren mit einem physischen Stempel auf einer Papierkarte, sabotiert das Personal es — nicht aus böser Absicht, sondern aus Überlastung zu Stoßzeiten.
Der Scanner von Ramen Joe wurde mit dieser Vorgabe im Kopf entworfen. Ein angemeldeter Mitarbeiter öffnet die App, richtet die Kamera auf den QR-Code des Gastes, und der Stempel wird in unter zwei Sekunden vergeben. Ohne Menüs, ohne Zwischenbestätigungen, ohne Tippen.
Die Berechtigung, Stempel zu vergeben, ist von der Berechtigung getrennt, ins Back-Office zu gelangen. Ein Kellner stempelt. Ein Betriebsleiter sieht Reports. Ein Gruppenadministrator ändert Regeln. Diese Trennung ist in Enterprise-SaaS trivial, wird aber in Gastronomiesoftware oft ignoriert — und dann wundert man sich, warum interner Betrug mit Punkten passiert ist.
Reservierungen: weniger Automatik, mehr Kontrolle
Jedes moderne Reservierungssystem hat eine Versuchung: alles automatisieren. Automatische Bestätigung, automatische Erinnerung, automatische Antwort auf Änderungen. In den meisten Fällen funktioniert das gut.
In der Qualitätsgastronomie funktioniert es weniger gut. Eine Reservierung für zwölf Personen an einem Samstagabend sollte nicht automatisch bestätigt werden, ohne dass jemand einen Blick in den Saal wirft. Ein Wunsch nach einem bestimmten Tisch sollte durch jemanden gehen, der das Haus kennt. Und Last-Minute-Ausnahmen brauchen einen Menschen.
Die Plattform von Ramen Joe erlaubt beide Modelle, Haus für Haus. Standardreservierungen laufen automatisch. Große Reservierungen oder solche mit Sonderwünschen kommen in eine Freigabeschlange. Und es gibt einen SMS-Kanal über Telnyx, der eine Stunde vor der Reservierung erinnert, was No-Shows reduziert hat, ohne Spam zu erzeugen.
Die SMS ist bewusst kurz. Name, Uhrzeit, Haus. Ein Link zum Stornieren. Sonst nichts. Das kommerzielle Paket wurde auf ein Startvolumen von 1.500 SMS pro Jahr ausgelegt, kalkuliert aus den erwarteten Reservierungen. Das ist keine technische Grenze: Die Kapazität lässt sich an das Wachstum anpassen.
Die Apps: iOS und Android zeitgleich veröffentlicht
Die iOS- und Android-Versionen wurden zeitgleich veröffentlicht. Die Android-App wurde später verfügbar, weil der Review-Prozess bei Google Play länger dauerte, nicht weil das Produkt in Phasen ausgerollt oder eine Plattform bevorzugt werden sollte.
Beide Apps wurden parallel entwickelt, mit demselben Wertversprechen: Reservierungen, Kundenbindung und eine konsistente Erfahrung auf beiden Plattformen. Der Unterschied im Moment der Sichtbarkeit in den Stores ergab sich rein aus den Freigabezeiten der jeweiligen Marktplätze.
Der Preis ist offensichtlich: zwei native Codebases statt eines Cross-Platform-Frameworks wie React Native oder Flutter. Es war ein bewusster Trade-off. Der Gewinn ist eine App, die sich verhält, wie die Plattform es verlangt, nicht wie der gemeinsame Nenner es zulässt.
Was in solchen Projekten schiefläuft
Die meisten Gastronomiegruppen, die eine solche Plattform bauen wollen, machen dieselben drei Fehler. Es lohnt sich, sie zu benennen.
- Sie fangen bei der App an. Ohne reifes Backend und ohne klare Geschäftsregeln wird die App zu einer hübschen Hülle, die das operative Chaos auf mobile Bildschirme spiegelt.
- Sie vertrauen auf WordPress-Plugins für Reservierungen und Kundenbindung. Das läuft für ein Haus. Es bricht bei fünf.
- Sie beauftragen Agenturen, die auf Projektbasis bauen und dann verschwinden. Software endet nicht beim Launch. Sie beginnt dort.
Das Gegenmittel für alle drei ist dasselbe. Behandle Software als Infrastruktur, nicht als Kampagne. Investiere zuerst in Fundamente — Backend, Datenbank, Authentifizierung, Berechtigungen, Continuous Deployment — und erst danach in sichtbare Oberfläche.
Best Practices, die sich gelohnt haben
Manche Entscheidungen wirken klein, hatten aber unverhältnismäßig großen Einfluss auf den Produktionsbetrieb.
Erstens: Git als einzige Quelle der Wahrheit. Jede Änderung geht über einen Commit, jedes Deployment läuft automatisch über GitHub Actions. Das eliminiert die Bug-Kategorie „läuft auf meinem Rechner“ und erlaubt Rollbacks in Minuten, falls in Produktion etwas bricht. Die offizielle GitHub-Dokumentation zu Continuous Deployment deckt die Prinzipien gut ab.
Zweitens: Internationalisierung ernst gemeint. Die Website läuft auf Portugiesisch und Englisch, mit zentralisierten Strings in Übersetzungsdateien. Das wirkt für ein Restaurant in Lissabon übertrieben, bis du merkst, dass 30 % der Gäste in touristischen Zonen kein Portugiesisch sprechen. Und dass die Expansion in eine neue Stadt leichter fällt, wenn das System mehrere Sprachen bereits unterstützt.
Drittens: Sandbox strikt von Produktion trennen. Ramen Joe hat eine Sandbox-Umgebung, die die Produktion spiegelt, aber mit Testdaten. Jede Änderung geht zuerst dorthin. Das senkt die Wahrscheinlichkeit, eine echte Reservierung beim Testen eines neuen Features zu zerbrechen.
Wo dieses Modell greift
Die Architektur von Ramen Joe ist nicht ramenspezifisch. Sie eignet sich für jedes Retail- oder Hospitality-Geschäft mit mehreren Standorten und einer Basis wiederkehrender Kunden. Restaurantgruppen, Café-Ketten, Barbershop-Netze, Kliniken mit mehreren Standorten, Fitnessstudios mit mehr als einem Standort.
Der gemeinsame Nenner ist dieser: Der Kunde ist einer, aber der Betrieb ist verteilt. Wenn deine Software das nicht abbildet, zahlst du in operativer Reibung, was du in Kundenbindung gewinnen solltest.
Key Takeaways
- Eine Gastronomiegruppe mit mehreren Häusern braucht eine einheitliche Plattform — fragmentierte Reservierungen kosten mehr als die Software, sie zu konsolidieren.
- Eine wirklich mehrstandortfähige Plattform erlaubt es, neue Standorte, Speisekarten und Betriebsregeln anzulegen, ohne technische Eingriffe an Website oder Apps anzufordern.
- Treue über Filialen hinweg ist nicht optional, wenn du echte Bindung willst. Dem Gast ist egal, in welchem Haus er ausgegeben hat.
- Native Apps rechtfertigen sich, wenn Wallet, Push-Benachrichtigungen und schnelle Kamera zentrale Teile der Erfahrung sind.
- Das Personal ist genauso Nutzer des Systems wie der Gast. Dauert der Ablauf länger als der alte, wird das System aus Überlastung sabotiert.
- Git als einzige Quelle, Sandbox getrennt von Produktion, Internationalisierung ab Tag eins. Das sind Fundamententscheidungen, die teure Refactorings später vermeiden.
- Der teuerste Fehler ist, mit der App zu beginnen, bevor das Backend reif ist.
Der natürliche nächste Schritt für eine Gruppe in dieser Phase ist nicht, mehr Features hinzuzufügen. Es ist messen. Welche Stempel führen zum zweiten Besuch. Welche Häuser halten besser. Welche Kampagnen bewegen wirklich die Nadel. Eine einheitliche Plattform macht diese Analyse möglich. Danach ist es eine Frage des Hinsehens.