Hospitality product

Restaurant QR menu app that guests actually use

Paper menus go stale the day a supplier changes a price. A restaurant QR menu app lets guests scan a code on the table, read the live menu on their own phone, and order from a list you can edit without a reprint. CodeLoop Studio designed, built, and still runs seeQRmenu (MenuOnScan) — so this page is not a mood board.

Case study

seeQRmenu (MenuOnScan)

We designed, built, and still run it. Guests scan a table code, read a live menu on the phone they already have — no App Store detour. Venues edit prices without a reprint. This page is not a mood board.

Open case

Paper goes stale the day a supplier changes a price

A restaurant QR menu app has one job: the kitchen and the guest see the same list. CodeLoop Studio in Sarajevo shipped that product as seeQRmenu (MenuOnScan). Guests should not download an app. The code on the table should open a fast page that works on any phone, in the language you set, with photos and prices that match the pass.

Staff need a simple admin: change a dish, hide an 86’d item, push a seasonal list. The QR stays put. If you run more than one venue, you need branded menus per location without five different vendors. If you are a founder building hospitality SaaS, we can ship the same pattern as a white-label product instead of a one-off brochure site.

Bars that also lose margin in the well often need inventory by weight — that is bar inventory, a different product. A full custom app (accounts, stores, notifications) is custom mobile app development. Typical studio products take 3–9 months from idea to launch; a focused QR-menu MVP can land faster. Written estimate within 24 hours via the online estimate.

The QR stays on the table. The list does not stay in a PDF.

Independent restaurants, café groups, hotel F&B, and bars that still hand out sticky PDFs are the usual brief. Guests should not download an app. A login wall at the table is how you lose the ticket. seeQRmenu opens in the phone browser: branded digital menus, live prices, photos, languages you set, 86’d items hidden between services. Managers edit without a developer and without calling a printer. Multi-venue groups get many QR sets and one ops model so the café next door is not wearing your template.

We built the product in Sarajevo and run it as hospitality software, not a city-only listing. We also build custom QR-menu products when you need your own brand, POS hooks, or multi-property admin. POS waits until the list is true and the docs exist. White-label if you are the SaaS, not the venue. A focused MVP can ship faster than a full platform. Studio-wide, typical mobile and web products take 3–9 months from idea to launch.

Hotels that also need a public site — rooms, map, enquiry, Booking.com stays — belong on hotel website development, a different job than a table code. After launch we stay for content ops, new locations, and the next hospitality feature. Send how often prices change, how many venues, who edits during service. If prices never change, you may only need a site. If they change weekly, paper is already costing you.

What has to be true at the table

No guest install

Scan, browse, done. A login wall at the table is how you lose the ticket.

Live prices

Admin edits, no reprint. The QR on the table does not change when the supplier does.

Works on any phone

Mobile web, fast on 4G. Photos that load. Language you set — not five fake flags.

86’d items disappear

Managers hide a dish between services. Guests should not order what the kitchen cannot fire.

Branded per venue

Your colours and dishes. Multi-venue groups need many QR sets, one ops model.

POS later, menu first

Hooks exist when the docs exist. v1 is a menu guests use. Ordering integrations wait until the list is true.

How we ship a hospitality menu product

  1. 01

    Service flow, not a template

    How tickets move, who edits, how many venues. A generic restaurant theme is how you reprint in PDF form.

  2. 02

    Menu information architecture

    Sections, allergens, photos, languages. Guests on a phone, not a desktop moodboard.

  3. 03

    Admin for non-technical managers

    Change a price without a developer. Hide an 86. Push a seasonal list.

  4. 04

    Web app from a scan

    QR that stays on the table. Then new locations and the next hospitality feature if we stay.

Before you brief a QR menu

  • How often prices change

    If the answer is “weekly,” paper is already costing you. If it is “never,” you may only need a site.

  • How many venues and languages

    One café versus a hotel F&B group is a different admin. White-label if you are the SaaS, not the venue.

  • Who edits during service

    A manager on a phone, not an IT ticket. Send it through the estimate form.

Frequently asked

No. A QR menu should open in the phone browser. That is how seeQRmenu works: scan the table code, read the live menu, no App Store detour.
Yes. The point of a digital menu is that the kitchen and the guest see the same list. Managers edit in admin; the QR on the table stays put.
No. We built the product in Sarajevo and it is used as a hospitality tool, not a city-only listing. We also build custom QR-menu products for teams that want their own brand and stack.
A focused MVP can ship faster than a full platform. Studio-wide, typical mobile and web products take 3–9 months from idea to launch. Send a brief to /online-estimate and we reply within 24 hours with a realistic range.
Yes. seeQRmenu is our own product; we also build custom hospitality software when you need different branding, POS hooks, or multi-property admin.

Related

Restaurant QR Menu App | Digital Menus by CodeLoop | CodeLoop Studio