QR menu for restaurants

The problem with a paper menu

A printed menu freezes the day it goes to the printer. The kebab that ran out at seven is still on the card at nine, last month's price is still the price a guest reads, and the new dessert is a handwritten line on the back page.

Every correction is a reprint, and between two reprints the menu quietly lies to the guest. The waiter absorbs the difference, one table at a time.

What Zabuno changes

The printed card stops being the menu and becomes a doorway. What the guest reads lives on your side and changes when you change it, so a sold-out dish is marked sold out on the next scan instead of on the next print run.

The address behind the code never changes, so the cards you already printed keep working after you rename a dish, raise a price, or point that table at a different menu.

How it works

Build the menu Create categories and dishes, set prices, attach photos and mark declared allergens.
Publish a version Publishing takes a numbered snapshot. Guests always read a published version, never your working draft.
Print the code Each code carries a 43-character token that cannot be guessed, so a code is not found by typing a neighbouring address.
The guest scans The scan resolves to the menu page and the server renders the HTML before it is sent. There is nothing to install and nothing to sign up for.
Change without reprinting Mark a dish sold out, publish a new version, or point the same code at another menu. The paper on the table stays the same paper.

What the guest page does

Readable without JavaScript: Categories are ordinary anchors and dishes are ordinary links, so browsing, prices, allergens and sold-out marks survive a browser that runs no scripts.
A dish has its own page: Photo, description, price, declared allergens and sold-out state, at an address a guest can send to a friend.
A permanent, sayable address: Besides the scan, every menu has a lasting address that reads like a name rather than a code, so it can go on a card, a window or a social profile.
Sold out says sold out: Out-of-stock and allergen states are written in words, not signalled by colour alone, so they still reach a guest who cannot tell the colours apart.
Prices in your currency, correctly: The decimal places follow the currency itself, and a price that cannot be resolved is hidden rather than shown wrong.
Built for a thumb: Tap targets stay at least 44 pixels, focus is visible for keyboard users, and motion is dropped when the phone asks for less of it.
Interface language, guest's choice: The surrounding interface can be switched between Turkish and English with a plain link that works without scripts.
Only dishes worth a page get one: A dish with no description, no photo and no allergen information is left out of search results and is not linked from the menu, because a link that leads nowhere is a lie.

What you need

On the guest side	A phone with a camera and a browser. No app, no account, no download.
On your side	A Zabuno account, one published menu and one printed code. Registering, building a menu, publishing it and printing a code work on the free plan.
For generating codes table by table	Producing codes for a whole floor in one pass belongs to a paid plan; producing them one at a time does not.
For your own colours on the guest page	Carrying your brand colour into the guest menu belongs to a paid plan. Without it the menu is shown in the neutral default.

What it does not do

No sizes, portions or extras A dish carries one price. Half portions, size options and paid extras are not part of the menu today.
No calories or nutrition values Allergens are shown because you declare them. Energy and nutrition figures are not stored and are not displayed.
Allergens are declared, not certified The page states which allergens you declared. It never claims a dish is free of anything, because a kitchen is not a laboratory.
Dish names are not translated Switching the interface language does not translate your menu. Dish names and descriptions stay in the language you wrote them in, and the page tells the guest so.
Guests do not pay here There is no payment step on the guest menu. Nobody enters card details on this page.
Offline replay is limited A menu opened from a scanned code can be shown again on a weak connection. The shareable permanent address has no offline behaviour.

Questions guests and owners ask

Does the guest need to install an app?

No. The code opens a web page in the browser that is already on the phone. There is no download and no account.

Do I have to reprint the codes when I change the menu?

No. The printed code points at an address that does not change. Edit a dish, publish a new version, or point the code at a different menu, and the same card keeps working.

What does a guest see when a dish has run out?

The dish is marked sold out in words on the menu and on its own page, from the moment you mark it. You do not have to publish a new version for that.

Can a guest send one dish to a friend?

Yes. A dish that has something to show has its own address, so the link opens on that dish rather than at the top of the menu.

Is the menu readable if scripts are blocked?

Yes. Categories, dishes, prices, allergens and sold-out marks are rendered by the server. Search and filters need scripts and are simply not shown without them.

Does it cost anything to start?

Registering, building a menu, publishing it, printing a code and serving it to guests are on the free plan. Paid plans add capability on top; they do not switch the basics on.

See what a plan includes

Plans, what each one adds and what the free one already covers.

Compare plans