Was wir aus 200 QR-Speisekarten gelernt haben

QR-Speisekarten waren während Corona ein Pflichtprogramm. Heute, 2026, sind sie wieder optional – und genau deshalb umso interessanter, weil nur die Restaurants weiter darauf setzen, denen es echten Mehrwert bringt. Mit Gastroscan.at betreuen wir mittlerweile Speisekarten von rund 200 Gastronomiebetrieben in Österreich. Hier eine ehrliche Auswertung dessen, was wir gelernt haben.

Warum überhaupt QR-Speisekarten?

Die kurze Antwort: Pflege. Eine gedruckte Speisekarte braucht 1–4 Wochen, bis sie geändert ist. Eine QR-Speisekarte ist in 30 Sekunden aktuell. Bei einem Wochenmenü, saisonalen Karten oder häufigen Preisanpassungen spart das pro Jahr viele Stunden Arbeit – und tausende Euro Druckkosten.

Die zweite Antwort: Daten. Welche Gerichte werden in der Karte am häufigsten angeschaut? Auf welchen Bildern bleiben Gäste hängen? Welche Allergen-Filter werden gesetzt? Diese Insights gibt es bei Druck-Karten nicht.

Was Gastronomen wirklich brauchen

In der ersten Version dachten wir: „Speisekarte zeigen, fertig.“ Falsch. Was Gastronomie-Kunden wirklich brauchen, sind:

• Multi-Sprachen ohne Übersetzungs-Stress: Deutsch, Englisch, Italienisch automatisch via DeepL, mit manueller Korrekturmöglichkeit für Eigennamen.
• Allergen-Kennzeichnung nach LMIV: Pflicht in AT/DE seit 2014, aber in der Praxis oft umständlich. Wir haben Allergene als Filter und Quick-Toggles eingebaut.
• Tageskarten / Wochenkarten: separate Bereiche, die nur an bestimmten Tagen erscheinen – ohne dass das Personal manuell ein-/ausschalten muss.
• Bilder, aber nicht zu viele: Bilder erhöhen den durchschnittlichen Bonwert um 8–15 %, aber zu viele Bilder verlangsamen die Karte und wirken unseriös.
• Schnelle Pflegbarkeit über Smartphone: Der Wirt steht in der Küche und ändert mal schnell den Preis am Handy – nicht im Office am Laptop.
• Druck-Backup: PDF-Export der aktuellen Karte für Wochen mit lahmem WLAN oder als Notfall-Karte für Stammgäste, die kein Smartphone bedienen wollen.

Tech-Stack

Anders als bei Buchly haben wir bei Gastroscan auf einen statischen Architekturansatz gesetzt:

• Frontend: Statische HTML-Seiten pro Restaurant, generiert aus JSON. Hosting auf Cloudflare Pages – Sub-100ms-Antwortzeit weltweit.
• Backend / Editor: Node.js auf Hetzner mit PostgreSQL. Generiert nach jeder Änderung neue statische Seiten und deployed automatisch.
• Bildverarbeitung: Sharp für serverseitige Komprimierung in WebP, AVIF und JPG-Fallback.
• Übersetzung: DeepL API mit Glossar-Funktion für Eigennamen und gastronomie-spezifische Begriffe.
• QR-Codes: selbst generiert mit qrcode-Library, mit eingearbeitetem Restaurant-Logo.

Was hervorragend funktioniert

Lighthouse 100/100/100/100. Statische Generierung + Cloudflare Pages = absurde Performance. Eine Speisekarte lädt im Restaurant-WLAN in unter 800 ms, auch auf alten Smartphones. Das macht im Gast-Erlebnis einen massiven Unterschied – niemand wartet auf eine ladende Speisekarte.

Mehrsprachigkeit als Killer-Feature. In Tourismusgegenden (Salzburg, Kärnten, Tirol) buchen Restaurants oft, weil sie nicht jährlich neue gedruckte EN/IT-Karten brauchen. DeepL-Übersetzungen sind 95 % druckreif, die restlichen 5 % lassen sich pro Gericht überarbeiten.

Wochenkarten-Logik. Den Mittagstisch nur Mo–Fr 11–14 Uhr anzeigen, das Sonntagsmenü nur am Wochenende – das geht in vielen Konkurrenz-Tools nicht oder nur umständlich. Bei uns ist es ein Klick im Editor.

Was nicht funktioniert hat

In-App-Bestellung. Wir haben in Version 2 versucht, eine Bestell-Funktion einzubauen, mit der Gäste direkt am Tisch bestellen können. Realität: Gastronomen wollen das mehrheitlich nicht. Bestellungen via QR fühlen sich für viele Gäste unpersönlich an, und für die Wirte ist die Anbindung an die Kassensysteme (Hyperpos, Vectron, OrderBird) jeweils ein eigenes Projekt. Wir haben das Feature nach 6 Monaten wieder abgeschaltet – und keine einzige Beschwerde dazu erhalten.

Drittanbieter-Themes. Versuch, Gastronomen eigene Templates wählen zu lassen. Resultat: 80 % wählten das Default-Template, 15 % wählten ein Premium-Template, das wir später wieder updaten mussten, 5 % wollten irgendwas Custom. Komplette Komplexität für minimalen Mehrwert. Heute gibt es zwei Templates: Default und „Edel“.

Komplexes Allergen-Modell. Erste Version hatte alle 14 LMIV-Allergene als separate Toggles. Resultat: Pflege war abschreckend, Gastronomen ließen Allergene oft komplett weg. Heutige Version: 14 Allergene als One-Click-Multi-Select pro Gericht, mit Warnhinweis wenn vergessen.

Insights aus 200 Speisekarten

• Die meisten Speisekarten werden zwischen 11:30 und 12:30 angeschaut – das Lunch-Window ist verlässlich
• Vegetarische und vegane Filter werden überraschend häufig benutzt – auch in „klassisch österreichischen“ Wirtshäusern
• Speisekarten mit hochwertigen Bildern haben eine 30 % längere Verweildauer und höhere durchschnittliche Bestellungen pro Tisch
• Englische Übersetzungen werden fast nur von echten Touristen genutzt – wer auf Englisch klickt, ist zu 90 % kein Stammgast
• Speisekarten ohne Preise (manche „Edel-Restaurants“) haben deutlich kürzere Verweildauer – Gäste sind verunsichert

Lessons für andere SaaS-Macher

1. Statische Generierung gewinnt. Wenn deine Daten sich nicht in Echtzeit ändern müssen, bau statisch. Performance, Kosten, Stabilität – alles besser.
2. Verstehe die Branche. Wir haben Wochen in Restaurants verbracht, mit Wirten geredet, mit Servicepersonal geschaut. Ohne dieses Eintauchen hätten wir die Wochenkarten-Logik nie so gebaut, wie sie heute ist.
3. Weniger ist mehr. Jedes Feature, das wir aus dem Produkt entfernt haben, hat das Produkt besser gemacht. Jedes Feature, das wir später hinzugefügt haben, hatte einen klaren, gemessenen Nutzen.
4. Pricing nahe der gefühlten Druckkosten. Eine gedruckte Speisekarte für ein Restaurant kostet pro Jahr € 800–2.500. Unser Pricing liegt bei € 19/Monat – ein Drittel der gedruckten Kosten, aber verständlich für Wirte. „Günstiger als Druck“ ist ein einfacher Verkaufspitch.
5. Kein Push-Marketing. 90 % unserer Kunden kommen aus Empfehlungen – ein zufriedener Wirt erzählt es dem nächsten. Marketing-Spend für Cold Acquisition ist verschwindend klein.

Was 2026/2027 kommt

Auf der Roadmap: Anbindung an Reservierungssysteme (Tisch reservieren direkt aus der Speisekarte heraus), Allergen-/Diät-Profile für wiederkehrende Gäste, AI-Vorschläge für Gerichte basierend auf Wetter und Tagesgeschehen. Aber alles in kleinen Schritten – und nur das, was Wirte tatsächlich wollen.

Fazit

Eigenes SaaS zu bauen heißt, jeden Tag zu wählen, was zu einem Produkt gehört und was nicht. Mit Gastroscan haben wir wieder gelernt, was Buchly uns schon beigebracht hat: Fokus, Branchenkenntnis und der Mut, Features wieder abzuschalten, sind wichtiger als jede coole Tech-Entscheidung.