A QR code menu without the ordering system
You do not need an ordering platform to put a menu on a table. Most of what comes up when you search this is order-and-pay software, which is a much bigger thing at a much bigger price. If all you want is the menu in front of the customer, that takes a page, a code and about an hour.
Use case5 min read
What you are actually buying
The companies advertising against this search mostly sell ordering systems: the customer scans, browses, orders and pays from their phone, and the order lands in the kitchen. That is a real product for a real job, it usually involves per-transaction fees or a monthly EPOS contract, and if table service is what you are trying to remove, it may well be worth it. This page will not help you choose one.
If the job is smaller, so is the kit. You need the menu to exist somewhere online, and a code on the table that points at it. That is the whole system. The rest of this page is about the three ways it goes wrong: the PDF, the laminate, and the reprint.
A PDF menu on a phone is usually a bad read
The obvious move is to upload the PDF your printer already has and point the code at that. It works, in the sense that something appears. But that file was designed for A4. On a phone it opens as a whole page scaled down to nothing, and the customer pinches in, drags sideways, loses their place between starters and mains, and gives up around the wine list. On mobile data it can also be a slow, heavy download for what is essentially a list.
The better destination is a plain web page. One column, real text rather than a photograph of text, prices next to the dishes. It reflows to fit whatever screen opens it, it loads fast, and a customer can zoom the type without losing the layout. Any website builder can produce this, and if your menu is short it is an evening’s work.
If a PDF is unavoidable, because the designer supplies one and nobody has time to retype it, ask for a second export shaped for a phone: single column, larger type, portrait. And note the trap that matters later on this page: many systems give a re-uploaded PDF a new address every time. A code pointing at menu-v3-final.pdf dies the day someone uploads version four.
Table tents, lamination and glare
A table tent that stands up beats a sticker laid flat on the table. Flat surfaces get wiped and sprayed all day, and a phone camera pointed straight down at a wet laminated sticker is fighting the ceiling lights.
- Laminate matt, not gloss. Gloss laminate reflects the light fitting above the table as a white streak, and if the streak crosses the code, some phones will not read it. Matt costs the same.
- Make the code bigger than the minimum. The floor is 15mm across, but a table tent gets scanned from a seated arm’s length and a 25mm code costs you nothing on an A6 card. The print guide has the numbers, including the empty border that must not be trimmed.
- Print the address in words under the code. A customer with a cracked lens, no signal on the camera app, or simple distrust of codes can type it. Keep it short.
- One per table and one at the counter, because tents migrate, and the odd one goes home in a coat pocket.
The cost nobody budgets: reprinting when prices change
Menus get redesigned rarely. Prices change all the time: the coffee contract goes up, a supplier drops a line, the kitchen adds a special that sticks. If the prices were printed on the table talkers themselves, every change is a design tweak, a print order and a round of swapping cards on tables. Nobody prices that in at the start, and it is why so many laminated menus are quietly wrong.
A code on the table has none of that cost, provided one thing holds: the address in the code has to keep pointing at the current menu. Edit the page, and every tent in the room is up to date, because the tents never contained the prices. The failure happens when the address itself moves. The PDF gets re-uploaded under a new name. The menu lived on a platform you stop using. The website gets rebuilt and the old link 404s. The pattern on the card is fine; the destination behind it is gone.
This is the static-or-dynamic decision, and it is worth two minutes. The full explanation is here, but the short version for a café: if your menu has a stable address on a domain you control, print a static code. It is free, from many tools, and no company can ever switch it off. If the address is outside your control, a PDF that moves, a hosted menu page tied to software you might leave, then a dynamic code earns its keep, because you can repoint it without touching a single tent. That is the one case where paying a small subscription beats paying the printer again.
Our part, stated plainly
The free plan is three codes, which covers a menu code, a Google review card and a spare. Paid plans start at £3.49 a month including VAT if you outgrow that. If you later cancel, everything already printed carries on resolving, which is the question we would put to any provider before sending artwork to a printer: here is what each of them says happens when you stop paying. Anyone can open an account, but payments are not switched on yet, so none of this is a checkout link in disguise.
Whichever tool you use, scan the printed proof at a real table, under the real lights, before you order fifty of them.
We make QR codes you can re-point after they are printed. The pattern on the page never changes, and the codes you have already printed keep working even if you stop paying.
Three codes free, no card. Paid plans start at £3.49 a month including VAT.