Lessons from 200 QR Menus

QR menus were mandatory during COVID. In 2026 theyre optional again – which makes them more interesting because only restaurants seeing real value still use them. With Gastroscan.at we now serve menus for ~200 hospitality businesses in Austria. Honest evaluation here.

Why QR menus at all?

Short answer: maintenance. A printed menu takes 1–4 weeks to update. A QR menu is current in 30 seconds. Weekly menus, seasonal menus, frequent price adjustments save hours of work and thousands of euros in print costs annually.

Second answer: data. Which dishes are viewed most? Which images do guests linger on? Which allergen filters get set? You cant get this from print menus.

What restaurants really need

First version we thought: "Show menu, done." Wrong. Restaurants really need:

• Multilingual without translation hassle: German, English, Italian auto via DeepL with manual correction for proper names.
• LMIV allergen labelling: mandatory in AT/DE since 2014 but cumbersome in practice. Allergens as filter and quick-toggle.
• Daily/weekly menus: separate sections appearing only certain days – without staff manually toggling.
• Images, but not too many: images raise average ticket 8–15 % but too many slow the menu and look unprofessional.
• Quick smartphone editing: the owner stands in the kitchen and changes a price on phone – not in the office on laptop.
• Print backup: PDF export of current menu for weeks with bad WiFi or for regulars who dont want smartphones.

Tech stack

Unlike Buchly, we chose static architecture for Gastroscan:

• Frontend: Static HTML pages per restaurant, generated from JSON. Hosted on Cloudflare Pages – sub-100ms response globally.
• Backend / editor: Node.js on Hetzner with PostgreSQL. Generates new static pages after each change and auto-deploys.
• Image processing: Sharp for server-side compression to WebP, AVIF and JPG fallback.
• Translation: DeepL API with glossary for proper names and gastronomy-specific terms.
• QR codes: Self-generated with qrcode library, restaurant logo embedded.

What works great

Lighthouse 100/100/100/100. Static generation + Cloudflare Pages = absurd performance. A menu loads in restaurant WiFi in under 800ms even on old smartphones. Massive impact on guest experience – nobody waits for a loading menu.

Multilingual as killer feature. In tourism areas (Salzburg, Carinthia, Tyrol), restaurants book because they dont need annual new printed EN/IT menus. DeepL translations are 95 % print-ready, the remaining 5 % editable per dish.

Weekly menu logic. Lunch only Mon–Fri 11–14:00, Sunday menu only weekend – this isnt in many competitor tools or only awkwardly. With us: one click in editor.

What didnt work

In-app ordering. Version 2 we tried building order function so guests could order at table. Reality: restaurants mostly didnt want it. Orders via QR feel impersonal to many guests, and POS integration (Hyperpos, Vectron, OrderBird) is its own project for owners. Switched off after 6 months – not a single complaint.

Third-party themes. Tried letting restaurants choose templates. Result: 80 % chose default, 15 % chose premium template we later had to update, 5 % wanted custom. Full complexity for minimal benefit. Today: two templates, Default and "Premium".

Complex allergen model. First version had all 14 LMIV allergens as separate toggles. Result: maintenance was offputting, restaurants often left allergens out entirely. Today: 14 allergens as one-click multi-select per dish, with warning if forgotten.

Insights from 200 menus

• Most menus viewed between 11:30 and 12:30 – lunch window is reliable
• Vegetarian and vegan filters used surprisingly often – even in classical Austrian taverns
• Menus with quality images: 30 % longer dwell time, higher average ticket per table
• English translations almost only used by real tourists – English clickers are 90 % non-regulars
• Menus without prices (some "premium" restaurants) have noticeably shorter dwell – guests get uncertain

Lessons for other SaaS makers

1. Static generation wins. If your data isnt real-time, build static. Performance, costs, stability – all better.
2. Understand the industry. We spent weeks in restaurants, talked to owners, watched servers. Without that immersion wed never have built weekly menu logic this way.
3. Less is more. Every feature we removed made the product better. Every feature added had a measured benefit.
4. Pricing near perceived print cost. Printed menu costs € 800–2,500/year. Our pricing € 19/month – a third the print cost, understandable to owners.
5. No push marketing. 90 % of customers come from referrals – satisfied owner tells the next. Cold acquisition spend negligible.

Whats coming 2026/2027

Roadmap: integration with reservation systems (book a table directly from menu), allergen/diet profiles for returning guests, AI suggestions based on weather and day. Small steps, only what owners actually want.

Bottom line

Building own SaaS means choosing daily what belongs and what doesnt. Gastroscan taught us again what Buchly already had: focus, industry knowledge, and courage to switch off features matter more than any cool tech decision.