Restaurant-Bestell-App mit KI bauen

Kurzantwort

Eine Restaurant-Bestell-App braucht vier Dinge, die zusammenspielen: QR-Codes, die an jedem Tisch ein Live-Menü öffnen, ein Menü, das sich in dem Moment aktualisiert, in dem ein Gericht ausverkauft ist, ein Küchendisplay, das die Bestellung in der Sekunde erhält, in der sie aufgegeben wird, und Status-Updates, die zum Gast zurückfließen, ohne dass jemand am Empfang ein Tablet anfassen muss. Greta baut alle vier als eine zusammenhängende App auf Ihrer eigenen Datenbank, sodass Sie aufhören, einer SaaS-Plattform pro Bestellung für Infrastruktur zu zahlen, die Sie komplett selbst besitzen könnten.

Warum zahlen Restaurants immer noch pro Bestellung für etwas so Simples?

Toast berechnet eine Plattformgebühr plus einen Anteil an jeder Online-Bestellung. Das Online-Bestell-Add-on von Square funktioniert genauso. ChowNow stellt eine monatliche Pauschale in Rechnung, die steigt, sobald man weitere Standorte hinzufügt. Keine dieser Zahlen ist geheim --- sie stehen auf den eigenen Preisseiten der Anbieter --- und alle teilen dieselbe Annahme: dass ein Restaurant seine Bestellsoftware nicht vernünftig selbst betreiben kann.

Diese Annahme ergab 2015 Sinn. Heute nicht mehr. Ein Bestellablauf für den Tischservice ist ein Menü, ein Warenkorb, ein Bestelldatensatz und ein Live-Statusfeld. Das ist für einen modernen KI-App-Builder ein Wochenend-Build, kein Sechsmonats-Engineering-Projekt --- und ist es einmal gebaut, sitzt kein Anbieter mehr zwischen Ihnen und jeder Transaktion.

Rechnen Sie es für einen mittelgroßen Betrieb durch: 120 Gedecke pro Abend, die Hälfte bestellt über Tisch-QR-Codes, bei 1,50 $ Plattformgebühr pro Bestellung. Das sind 90 $ pro Abend, etwa 2.700 $ im Monat, auf ewig, für ein Feature, das im Kern ein Formular und ein Datenbank-Write ist.

Was braucht eine hausinterne Bestell-App eigentlich?

Nicht viel, und genau das ist der Punkt. Vier Teile, jedes mit einer Aufgabe:

• QR-Tischbestellung --- jeder Tisch bekommt einen Code, der auf ein Menü zeigt, das auf diese Tischnummer beschränkt ist, sodass eine Bestellung genau weiß, wohin sie geroutet wird, ohne dass ein Kellner sie eintippt.
• Live-Menüverwaltung --- der Inhaber oder Manager ändert Preise, setzt ein Gericht auf "ausverkauft" oder fügt vom Handy aus ein Tagesgericht hinzu, und es ist sofort überall live. Kein App-Store-Review, kein Warten auf den Update-Zyklus eines Anbieters.
• Küchendisplay-Sync --- der Bon erscheint in dem Moment, in dem die Bestellung aufgegeben wird, auf einem Bildschirm in der Küche, sortiert nach Tisch und Zeit, und ersetzt den Drucker, der beim Freitagsansturm klemmt.
• Bestellstatus-Updates --- "eingegangen", "in Bearbeitung", "fertig" werden auf das Handy des Gastes gepusht, sodass niemand am Pass herumsteht und sich fragt, ob das Essen bald kommt.

Das Datenmodell dahinter

Es ist einfacher, als es klingt. Ein Restaurant hat Table-Datensätze, jeweils mit QR-Code und ID. MenuItem-Zeilen gehören zu Kategorien und tragen ein available-Boolean, das die Küche oder der Manager in Echtzeit umschaltet. Jede Order ist mit einem Tisch verknüpft (oder einem Abholzeitfenster für Takeout) und enthält OrderItem-Zeilen mit Menge und Zusatzoptionen. Ein status-Feld an der Bestellung --- aufgegeben, bestätigt, in Zubereitung, fertig, abgeschlossen --- ist die einzige verbindliche Quelle, aus der sowohl das Küchendisplay als auch das Handy des Gastes lesen. Greta baut das auf Supabase Postgres mit Prisma auf, und das Ganze passt bequem in fünf oder sechs Tabellen.

Wie bleibt das Küchendisplay eigentlich synchron?

Das ist der Teil, den die meisten DIY-Versuche falsch machen. Alle paar Sekunden die Datenbank nach neuen Bestellungen abzufragen, funktioniert in einer Demo gut und bricht am Samstagabend um 19:30 Uhr zusammen --- der Küchenbildschirm hinkt hinterher, Bons stapeln sich in falscher Reihenfolge, und am Ende läuft ein Kellner zurück, um nachzuschauen.

Greta verdrahtet das stattdessen über die Realtime-Subscriptions von Supabase statt über Polling. In dem Moment, in dem sich eine Zeile in der orders-Tabelle ändert, bekommt jeder abonnierte Client --- das Küchendisplay, die Statusseite des Gastes, das Dashboard des Managers --- das Update über eine Websocket-Verbindung gepusht. Kein Refresh-Button, keine Fünf-Sekunden-Verzögerung, kein verpasster Bon. Es ist dasselbe Echtzeit-Muster, das unter vielen kollaborativen Apps steckt --- es ist nur zufällig genau das, was eine Küche braucht.

Vergleich: Plattform mieten vs. App besitzen

Was ist mit Takeout und Abholung, nicht nur Tischservice?

Dasselbe System, anderer Einstiegspunkt. Eine Abholbestellung überspringt die Tischzuweisung und bekommt stattdessen eine versprochene Fertigstellungszeit, was letztlich nur ein Zeitstempelfeld am selben Order-Modell ist, mit einem anderen angehängten Ablauf --- kein Tisch-QR-Code, aber dasselbe Küchendisplay, dieselbe Status-Pipeline, dasselbe Menü. Sie pflegen nicht zwei Apps, sondern ein Bestellmodell mit zwei Eingängen. Schreiben Sie dem Gast per Twilio eine SMS, wenn die Bestellung fertig ist, oder lassen Sie ihn einfach auf seinem eigenen Handy zusehen, wie sich der Status von "in Zubereitung" zu "fertig" ändert.

Häufige Fehler beim Bauen

• Die SaaS-Feature-Liste kopieren statt den tatsächlichen Ablauf des Restaurants. Die meisten Restaurants mit einem Standort brauchen am ersten Tag keine Treuepunkte oder ein Prämien-Wallet. Liefern Sie Tischbestellung, Live-Menü, Küchen-Sync, Status-Updates --- und fügen Sie dann hinzu, was Gäste tatsächlich verlangen.
• Das Küchendisplay als Nachgedanken bauen. Das ist der Teil, der am härtesten genutzt wird, jede einzelne Schicht, unter Druck. Testen Sie es vor dem Launch mit einem echten Bildschirm in einer echten Küche, nicht nur mit einem Laptop am Schreibtisch.
• Den "Ausverkauft"-Ablauf überspringen. Ein Menü, das ein Gericht nicht in Echtzeit auf "nicht verfügbar" setzen kann, nimmt Bestellungen für Essen entgegen, das es nicht gibt --- und das ist ein schlechteres Erlebnis als jede App-Store-Verzögerung.
• Annehmen, ein Standort bedeutet, man braucht nie einen zweiten. Das obige Datenmodell skaliert mit nahezu keinem Mehraufwand auf mehrere Restaurants, wenn Restaurant von Anfang an eine vollwertige Tabelle ist und nicht später angeflanscht wird.

FAQ

Brauche ich trotzdem einen Zahlungsdienstleister wie Stripe oder das Kartenlesegerät von Square? Ja --- Greta ersetzt nicht die Zahlungsschienen, sondern die Bestell- und Menüsoftware, die darauf aufsetzt. Stripe wickelt die Zahlung ab; Ihre App kümmert sich um alles drumherum.

Müssen Gäste eine App herunterladen? Nein. Ein QR-Code öffnet eine Webseite. Das ist weniger Reibung als eine App-Store-Installation, und deshalb verzichten die meisten modernen Bestellabläufe auf der Gästeseite komplett auf native Apps.

Wie lange dauert ein solcher Build eigentlich? Der Kernablauf --- QR-Bestellung, Menüverwaltung, Küchendisplay, Status-Sync --- ist mit Greta realistisch in Tagen umsetzbar, nicht in Monaten, weil das Datenmodell klein und die Echtzeit-Schicht ein bekanntes Muster ist, kein Forschungsprojekt.

Kann ich das über mehrere Standorte hinweg betreiben? Ja, wenn die Beziehung zwischen Restaurant und Table von Anfang an dafür ausgelegt ist. Ein zweiter Standort wird ein neuer Restaurant-Datensatz, kein neuer monatlicher SaaS-Vertrag.

Was passiert, wenn ich das Hosting später wechseln möchte? Nichts Dramatisches. Es ist Ihr Next.js-Codebestand in Ihrem GitHub-Repo und Ihre Daten in Ihrer eigenen Postgres-Datenbank --- exportieren, neu deployen, fertig. Genau darum geht es, wenn man nicht auf einer gemieteten Plattform baut.

Fazit

Die Technologie ist hier nicht mehr der schwierige Teil. Tischbestellung, ein Live-Menü, ein synchronisiertes Küchendisplay und Status-Updates sind ein gut verstandenes Muster, und ein KI-App-Builder kann dieses Muster schnell zusammensetzen. Die eigentliche Entscheidung ist, ob Sie weiterhin pro Bestellung dafür zahlen oder es einmal besitzen und den Zähler stoppen wollen.

Beginnen Sie noch heute, Ihre App mit Greta zu bauen.