What happens to your QR code when you switch menu tools

Most restaurants pick a QR menu tool in an afternoon and then live with it for years. Not because it's great — because leaving looks expensive, and nobody can quite tell how expensive until they try.

This is the question worth asking *before* you commit: if this tool turns out to be wrong, what does it cost me to walk away? The answer is almost entirely decided by one thing, and it isn't the subscription.

The only question that really matters

Who controls the URL your printed QR code points at?

Everything else — export formats, contract length, how helpful support is — is a rounding error next to this. Your menu data is a few dozen lines of text you could retype in an evening if you had to. The codes you printed and stuck on forty tables are the part you can't redo cheaply.

There are three arrangements, and they are not equally reversible.

Static codes: permanent, for better and worse

A static QR code has the destination baked into the pattern itself. Nothing sits in the middle. Scan it and the phone goes straight to that address.

The upside is real: nobody can take it away from you, there's no redirect service to shut down, and it works forever with no ongoing dependency.

The downside is the same fact from the other side. That code can *never* be repointed. If you leave the vendor whose domain is in the URL, every printed code is dead paper. Static codes are free on almost every tier precisely because they cost the vendor nothing to issue — there's nothing to keep running.

Vendor-redirect codes: flexible, until they aren't

A dynamic code points at a short URL on the vendor's domain, which forwards to your menu. Because the vendor controls the redirect, it can be repointed later — which is genuinely useful, and why dynamic codes are usually a paid feature.

But look at what you've accepted. That redirect is now a permanent dependency on a company you may be trying to leave. If they shut down, change their domain, discontinue the free tier you're on, or simply decide your plan no longer includes dynamic codes, every printed code stops working. You can't fix it yourself, because you don't control the hop in the middle.

This is the arrangement most restaurants end up in without ever deciding to.

A stable URL you'd keep anyway

The third option is a code pointing at an address that doesn't need to change when anything else does — because the vendor treats a permanent URL as a feature rather than a lever.

The strongest version is a custom domain you own: menu.yourrestaurant.com, pointed wherever you like. Then switching tools is a DNS change and your printed codes never know it happened. If custom domains aren't available, the next best thing is a vendor who commits that your URL is stable — that it survives menu edits, plan changes, and re-uploads.

The failure mode to watch for is subtle and common: some tools mint a *new* URL when you re-upload a corrected menu. No warning, no redirect from the old one. Your codes were fine yesterday and point at a 404 today. Free file-sharing links are the worst offenders, but they aren't alone.

What actually transfers

Beyond the URL, here's what a move involves in practice:

• Your menu content. Realistically the easy part. If you can't export, a tool that reads a photo or PDF of your existing menu can reconstruct it in minutes — which is the same capability that got you set up the first time.
• Your QR codes. Covered above. This is the whole game.
• Your search presence. Rarely discussed and slowly expensive. If your menu page has been indexed and accumulating history, moving to a new address resets that unless the old URL redirects to the new one permanently. Most vendors will not maintain a redirect for a customer who left.
• Your analytics history. Gone, usually. Worth knowing before you plan around it rather than after.

Five questions to ask before you sign up

Ask these of any vendor, including us:

1. Is my QR code static or dynamic? If dynamic, whose domain does it route through?
2. Does my URL ever change? Specifically: when I edit the menu, when I re-upload it, or when I change plans.
3. Can I use my own domain? If yes, leaving becomes a DNS change instead of a reprint.
4. Can I export my menu? In what format?
5. If I cancel, what happens to the URL? Does it 404 immediately, redirect, or stay up?

A vendor who answers these quickly and specifically is telling you something good. One who has to check is telling you something too.

Where we stand

1prairie.menu publishes to a permanent address that doesn't change when you edit your menu, change your prices, or re-upload it. Edit the page as often as you like — the printed code keeps working, because the URL is the thing we treat as fixed.

We're not going to pretend the lock-in problem is fully solved. Custom domains are on our roadmap and not shipped yet, which means today your menu lives at an address on our domain. That's the honest state of it. What we can say is that the URL is stable by design rather than by accident, and that we'd rather tell you where the limit is than let you find it later.

If you're still choosing, our roundup of QR code menu makers covers the wider field, and where to host your restaurant menu online goes deeper on what a good host actually owes you.

The short version

Print a static code and you've chosen permanence — make sure it's an address you're happy to keep. Print a vendor-redirect code and you've chosen flexibility, rented from someone else. Get a URL you'd keep anyway, and switching costs you an afternoon instead of a reprint.

Decide which of those you're signing up for *before* the codes go on the tables.