QR code menu in a restaurant — create it once and never reprint it

Everyone advises the same thing: generate a QR code, put a link to the menu in it, print it, and you're done. In my opinion, it is the stupidest possible way to do it. And in a moment, I will show you why.

First, a picture. Friday, room full, waiter running around like crazy. At table seven, a group of three guests has been waving their phone over a greasy sticker for five minutes. The code leads to a PDF from two seasons ago. Half the dishes are unavailable. Prices are made up. Finally, they ask for a paper menu, which you no longer print. Sound familiar? Exactly.

A QR code menu is not a gadget. It is your most frequently touched "button" in the entire establishment. And it is usually created in such a way that problems are written into the script from day one.

The code that encodes the file is one-time use (you just don't know it)

Classic. You generate a QR code that contains a direct link to menu-wiosna-2025.pdf. You print, laminate, engrave on tags, and place them on the tables. Beautiful. Works until the first change in the menu.

Because you are changing the beer supplier. Or you are raising the price of a burger by three zlotys. Or a seasonal menu is being introduced. And suddenly, that lovely laminated code leads to outdated content. You have two choices: leave the lie on the table or reprint everything from scratch.

The QR code itself is stupid. It is literally an image that encodes a piece of text. If you have embedded a long, rigid address to a file into it, then you are married to that address. For better or for worse.

And the entire remedy fits into one sentence. The code is not supposed to lead to a menu. It is supposed to lead to a short link, whose destination you can change whenever you want.

In practice it looks like this

Instead of encoding a little monster in a QR code like:

https://twojarestauracja.pl/uploads/2025/menu-final-v3-NEW.pdf

you are encoding a short intermediate address:

https://cutty.dev/u/menu

This link never changes. Only where it leads changes, and you can set that in the panel in thirty seconds. Today it opens a spring menu. Tomorrow a winter one. In a month, you'll switch it to a PDF with wines at the bar. Stickers on the tables? The same ones. You swap the destination, not the paper. That is the whole trick and there really is no hidden catch.

Recipe for code that you write once and forget

One after another.

First, make the menu as a webpage, not as a PDF. This is important. A PDF on a phone is a disaster: you have to zoom in, scroll sideways, and with poor signal in a venue's basement, it takes ages to load. A regular HTML subpage opens instantly and is readable on every screen, even on that cracked one worth fifty zlotys.

Then create a short link with a sensible ending. Something like /u/menu or /u/karta. It will be useful when a guest prefers to type the address manually or when you provide it to them over the phone during a reservation ("dot dev, slash menu").

From this short link, you generate a QR code. One. Time. In cutty.dev, you do it immediately from the ready-made link, so you don't jump between three tools and don't fiddle with which PNG file was the right one.

You print and distribute. Hangars, stickers, a sticker at the entrance, a poster in the window for those to go.

That's it. From now on, changing a card is one edit in the panel. The paper stays in place.

Scans tell you more about a place than you think

Here is the thing that most restaurateurs simply ignore. A short link provides scan statistics. And these are not dead numbers to be framed, but knowledge about your own establishment.

You will see how many times the menu was opened on Friday evening, and how many on Tuesday afternoon. Create a separate code for lunch and a separate one for the evening menu, and you will see what time dinner actually starts for you (usually not when you think). A separate code for the wine list will show you the brutal truth: whether anyone even looks at it at all.

And now attention, because this matters. In cutty.dev, we collect these numbers without building a guest profile. IP goes through a hash, there are no advertising trackers, and there is no customer file. You get the number of scans and the trend over time, which is exactly what helps run a restaurant, rather than turning a plate of spaghetti into personal data. In the EU gastronomy sector, where GDPR is breathing down your neck, this is the difference between "we have statistics" and "we have a problem with the inspector."

A few little things that save nerves. The menu and scan data remain on servers in the EU, so one less topic for a conversation with the accountant. The guest doesn't have to create an account or click through a wall of consents, because nothing ruins your appetite like a cookie-wall before cod. And this same replacement mechanism will also handle the promotion of the day or a post-visit survey. It is enough to briefly redirect the existing link.

A good QR code menu is boring. You print it once, it hangs for years, and it never lies about prices. Boredom is a compliment here.

So when next time someone advises you to "drop the link to the menu in the code and print it," smile and do something else. A short, replaceable link underneath (for example cutty.dev) allows you to update the card with one click, rather than stickers on thirty tables. Your waiter from table number 7 will thank you.