Used POS systems for restaurants: what actually transfers
The hardware is the cheap part and it is the only part that actually transfers. Everything that makes it work belongs to somebody else.
Home / Blog / Qr meny: the code takes an afternoon, the menu takes a week
Printing the square takes an afternoon. Writing a menu somebody can decide from on a small screen takes considerably longer, and it is the half that gets skipped.
Anzul Aqeel · Founder & Director, Anunzio International FZC · 2 September 2026
The phrase arrives in a dozen spellings and they all mean the same thing, so this is not an article about how it is typed. It is about what happens when the code works perfectly and the page opens in under a second. The guest is then handed 140 dish names in one column, with no photographs, no groupings that mean anything, and a scroll bar the length of a receipt.
A qr meny is a printed code that opens a restaurant's live menu on a guest's phone, replacing the laminated card. The technical half is solved and cheap. The editorial half (deciding what the menu says, in what order, with which choices attached) is where the good ones separate from the rest.
Treat it as a rewrite rather than a conversion. A paper menu is read all at once on a large surface, with the eye jumping around; a phone screen shows perhaps eight lines at a time and is read strictly downwards. Copying one into the other produces a document that technically contains everything and helps nobody.
A guest gives a menu a few seconds of attention before they either choose or ask a human. Nielsen Norman Group's eye-tracking research shows people scan a screen in fragments rather than reading it line by line, so the first screen has to contain something orderable rather than a table of contents. That usually means the categories people actually came for, in the order the room sells them, with the slow-moving specialities further down.
There is a reliable test for this. Open your own menu on your own phone, hold it at arm's length in a badly lit room, and count how far you scroll before the first thing you would actually pay for appears. What is usually in the way is a section of drinks or a breakfast list that has sat at the top since the day the menu was first typed. That list is harmless on a wide card and expensive on a narrow screen.
Category order is worth arguing about once a quarter. Breakfast items sitting above a lunch list at two in the afternoon push everything useful below the fold, and a section named "Chef's Selection" tells a hungry person nothing. Categories and items carry a sort order you can change from the admin, which makes this a job of about 5 minutes rather than a support ticket. That matters, because a menu you can rearrange cheaply is a menu that gets rearranged when it is wrong.
Write for the guest who does not know the dish, without patronising the one who grew up on it. The local name stays as the headline because that is what regulars search for and order by; a short second line does the explaining.
Six or seven words is usually enough: the protein, the method, and the thing that surprises people. A visitor deciding between two unfamiliar names will pick the one they can picture, every time. This is also where heat lives: if a dish is genuinely hot, say so in the description rather than assuming the photograph communicates it.
Halal status, pork and lard, alcohol in a sauce, nuts, shellfish and dairy decide whether an order happens at all for a large share of guests. In Malaysia, halal certification runs through JAKIM's official halal portal, and a guest looking for that word will not order until they find it. On paper these get compressed into a legend of symbols nobody can see in low light; on a phone there is room to write them next to the dish they belong to.
Where a choice changes the answer, make it a choice rather than a note. Required choices and limits the kitchen can trust are the mechanism. A guest must pick a spice level, may pick at most 3 variants of a side, and cannot submit an order the kitchen would have to phone back about. Options and add-ons carry their own prices, so extra cheese is priced by the system rather than remembered at the counter.
The menu is the only part of this whole product a restaurant cannot outsource to us. We can make it fast, honest and reorderable in seconds, but somebody who has actually cooked the food has to decide what it is called and what a guest needs to know before they tap it.
— Agha Shah Zaman, co-founder of Get Menu
Photograph the dishes that are hard to imagine and the ones you want to sell more of, and leave the rest as text. A menu where every item has a picture scrolls forever and flattens the difference between your signature plate and a side of rice.
The practical constraints matter as much as the art. Photos are compressed automatically here so a page still opens quickly on a weak mobile signal in a room full of concrete. A photo style setting can render every image in colour or in black and white so a category reads as one set. Among the 12 page layouts there are text-only ones for menus that work better without pictures. A consistent crop across a category does more for how a menu reads than any single good photograph.
A qr code menu is only better than paper while it stays accurate, and accuracy is a system property rather than a discipline. Counts per item fall as orders arrive and sold out flips itself at zero, with no one watching, so the dish that ran out during the rush stops being offered instead of being apologised for.
Prices follow the same rule: every line is re-priced from the live menu at checkout, so a change made during service applies to the cart that has been open since before it. Where the code is on a table (one generated for every table) the order arrives with its own location attached and a ticket lands in the managers' group without anybody carrying it. The confirmation goes the other way at the same speed: 3 messages leave on an order in roughly 2 seconds, so nobody at the counter is typing replies during a rush. Rewards that expire keep the returning-guest side honest too, because a reward with no end date is one nobody ever gets around to using.
Fewer than the paper one, in most cases. The screen makes length obvious in a way a folded card hides, and kitchens that cut a menu when moving to a phone usually find their prep and waste improve at the same time. If a section has not sold in a month, the phone is a good excuse to retire it.
Only if you can keep every version true. Two languages means two menus to update, and a stale second version is worse than none because a guest will order from it. The workable pattern here is one record per dish: the local name as the headline, the translation on the description line beneath it, so a price change still happens exactly once.
No. The bill is settled in cash or on the restaurant's own card machine, which also means there are no card details held anywhere in the system. It removes an entire category of thing that can go wrong at a table on a Friday night.
Loading it is quick: a spreadsheet upload rather than typing, then an export to a spreadsheet whenever you want the current version back. Writing good descriptions and deciding the required choices is the part that takes a week of evenings, and it is worth every one of them. The trial runs 15 days with no card asked for, and order details are cleared after 120 days.
Further reading
The hardware is the cheap part and it is the only part that actually transfers. Everything that makes it work belongs to somebody else.
Commission is the only software bill that grows every time the kitchen has a good night, and most owners have never worked out the month's total on paper.
One city wrote the fees into law, which makes them the clearest public numbers available on what delivery actually costs a restaurant.
Fifteen days with everything switched on. No card, no commission, ever.
Questions from other owners are answered in the community.