Make a Digital Menu With AI (QR-Ready, and You Can Change Prices Anytime)

TLDR: To make a digital menu with AI, feed the model your real dishes, prices, and a short honest line for each, then ask for a single self-contained HTML page built phone-first, with clear sections, dietary tags, and a sold-out state. Art-direct the look so it feels like your room, not a template. Then publish it as a live page, point one QR code at that link, and update prices on the same URL so the code on the table never has to be reprinted.

A menu is the most-read document your restaurant will ever produce, and most of them are working against you. The laminated card goes stale the day your supplier raises a price. The PDF someone stuck behind a QR code opens as a tiny, un-zoomable rectangle that people give up on before they reach dessert. Neither one is a menu. They are pictures of a menu.

You can do much better in an afternoon, and you do not need a designer, a developer, or a monthly menu-app subscription. This is a walkthrough for how to make a digital menu with AI: a real web page that reads beautifully on a phone held in one hand, groups your dishes so guests order more, and sits behind a single QR code you print once and never touch again.

Why a digital menu, and why a real page

A digital menu is not automatically a good menu. A PDF is digital, and it is miserable on a phone. What you actually want is a web page, because a page adapts to the screen, stays legible at any size, and can be changed in seconds without anyone downloading anything.

Here is the honest comparison, from the guest’s phone and from your side of the counter.

The printed menu wins on nothing except the moment the ink is fresh. The PDF loses on the one thing that matters most: it is unreadable on the device every guest is holding. A real page is the only option that is both current and comfortable to read.

What goes into a menu before you prompt

The AI is only as good as the content you hand it, and this is the step people skip. Gather the real thing first, in plain text, so the model builds from your kitchen and not from its imagination:

• Every dish, grouped into sections. Starters, mains, sides, drinks, dessert. However your kitchen thinks about it.
• A price for each. Exact numbers. The model should never guess a price.
• One honest line per dish. What it is, the two ingredients that make it worth ordering, and nothing else. “Charred broccolini, chili, lemon, pecorino” sells. “A delicious vegetable medley” does not.
• Dietary and allergen tags. Vegetarian, vegan, gluten-free, contains nuts. Decide your labels now so they are consistent.
• The details around the food. Service hours, whether prices include tax or service, and anything you repeat to guests all night.

Spend twenty minutes here and the rest is fast. Hand the model a vague brief and you will spend the afternoon correcting invented dishes.

The prompt that builds a phone-first menu

Once you have the content, one well-shaped prompt gets you a working page. Notice how much of it is about the phone and about your specific dishes, not about “a menu” in the abstract. Copy this, paste your real content where it says, and adjust from there.

Build me a digital restaurant menu as a single self-contained HTML page.
It is for [restaurant name], a [type, e.g. neighborhood Italian] spot, and
it will be opened on phones from a QR code at the table.

Design it phone-first: one column, large readable type, generous spacing,
and high contrast so it is easy to read in a dim dining room. It should
still look good on a laptop, but the phone is the priority.

Structure it in these sections, in this order: [list your sections]. For
each dish show the name, a short description, the price aligned to the
right, and small tags for dietary info (V, VG, GF, N for nuts). Put a
short "Chef's pick" highlight at the top of each section.

Use this exact content, do not invent or change dishes or prices:
[paste your full dish list, prices, descriptions, and tags]

Style: [describe the feel, e.g. warm and rustic, cream background, deep
terracotta accent, a serif for headings]. Add the restaurant name, a
one-line tagline, and service hours at the top, and a small footer note
that prices include tax.

Deliver ONE complete, self-contained HTML file with all CSS inlined,
no external fonts or images loaded from the internet.

That last line matters more than it looks. A single self-contained file is what makes the menu easy to publish and impossible to break in transit. If the model ever hands you loose fragments instead, there is a short guide to getting self-contained HTML out of AI that fixes it in one reply.

Here is the shape of what you are building, from your content to the phone on the table.

Organize the menu so people order more

A menu is a sales document disguised as a list. How you arrange it changes what people order, and the AI will happily follow your structure once you give it one.

• Group the way people order, not the way you cook. Guests think “something to start, a main, a drink.” Sections that mirror that flow are easier to scan than a kitchen-station layout.
• Lead each section with a highlight. Putting a “Chef’s pick” or a signature dish at the top of a section pulls the eye and pulls the order. People pick from the top of a list far more than the middle.
• Keep descriptions short and concrete. Two or three ingredients that matter, no adjectives doing the work that ingredients should. Specific beats flowery every time.
• Do not price everything in a neat column of round numbers. A tidy vertical stack of prices invites people to compare on cost. Let the price sit quietly after the description instead of lining them all up for a spreadsheet read.

If you want the reasoning behind layout choices like these, the piece on the anatomy of a report people actually read covers the same instinct: structure the page for how a busy person’s eye moves, not for how the author thinks.

Make it feel like your restaurant, not a template

The fastest way to spot an AI-built page is that it looks like every other AI-built page: the same soft gradient, the same rounded cards, the same default blue. Your menu should feel like walking into your room. That is a prompting problem, and it is a solvable one.

Give the model real art direction. Name the mood, the palette, and the type. “Warm and rustic, cream paper background, deep terracotta accent, a classic serif for the dish names.” “Clean and modern, near-black background, one bright accent, tight sans-serif.” The vocabulary you use to steer this is worth learning; there is a whole list of feel words that art-direct AI output, and a broader method for how to brief AI like you would brief a designer.

Then iterate. The first draft will be close and slightly off, and fixing it is a conversation, not a restart. “Make the section headers larger and add more space above them.” “The tags are too loud, make them small and gray.” Short, specific notes, one pass at a time, the same rhythm that works for iterating on any AI-generated page. If the result still feels generic, the guide to making AI pages look less generic has the specific fixes.

The details most menus forget

The difference between a menu that works and one that generates questions all night is a handful of small things. Ask for them explicitly:

• Allergen and dietary tags, consistently placed. A small V, VG, GF, or N next to each dish saves your staff a hundred conversations and helps guests order with confidence.
• A sold-out state. Ask the model to build a “sold out” style you can apply to any item, so when the kitchen 86s a dish mid-service you dim it and add a tag instead of pretending it is still available.
• Service hours and what the price includes. A line at the top for hours and a footer note about tax or service charge heads off the two most common questions.
• It has to read on a phone in a dim room. High contrast, large tap targets, one column. A menu that looks great on your laptop and fails on a phone in the actual dining room is a failure. The checklist in making AI pages mobile-friendly applies directly here.

Here is the anatomy of a single menu section done well, so you know what to aim the AI at.

Publish it, and put it on the table

Now the page has to leave your laptop, because a menu only your kitchen can see is not a menu. This is the step where a real web page pays off, and it is genuinely simple.

Take the self-contained HTML the AI produced and publish it with VisiblePage. You paste the HTML, or drop a ZIP if the project grew into multiple files, and you get a live URL immediately, with no build step, no hosting account, and no menu-app fees. Generate a QR code that points at that link, print it on a table tent, a sticker, or the window, and you are open. Guests point a camera, the menu opens in their browser, and every tag, price, and section is exactly as you designed it, loading fast from the edge.

Two things make this the right home for a menu specifically. First, the page lives at one canonical link, so when a price moves or the kitchen 86s a dish, you edit the page and re-publish to the same URL. Every QR code on every table already points there, so it keeps working and shows the new version with nothing to reprint. That single fact is the whole reason a digital menu beats a printed one. Second, you can put the menu on your own address, like menu.yourrestaurant.com, with one custom domain record, so it reads as part of your restaurant and not a random link.

Try it now: Publish your AI-built menu with VisiblePage and get a QR-ready live link in seconds.

Frequently asked questions

Can AI really build a usable restaurant menu?

Yes. Give an AI model your dishes, prices, and descriptions and ask for a single self-contained HTML page, and it will produce a clean, phone-friendly menu with sections, dietary tags, and your styling. The quality comes from feeding it real content and describing the look you want, not from the model guessing what your restaurant serves.

How do people open a digital menu at the table?

You publish the menu as a live web page, generate a QR code that points to that link, and print the code on a table tent, a sticker, or the window. Guests point their phone camera at it and the menu opens in their browser instantly, with no app to download.

How do I change a price without reprinting the QR code?

Keep the menu at one canonical link and update the page itself. When you edit a price or mark a dish sold out and re-publish to the same URL, the QR code on every table already points there, so it keeps working and shows the new version with nothing to reprint.

Do I need a developer or a monthly menu app?

No. You can make the whole menu with an AI model and publish it as a single page. There is no build step, no menu-app subscription, and no per-item fees. You own the page and the content, and you change it whenever the kitchen changes.

Will the menu work on every phone?

If you ask for a phone-first, self-contained page, yes. It is a normal web page, so it opens in Safari, Chrome, and every mobile browser with no install. Ask specifically for large tap targets, high contrast, and a single-column layout so it reads well one-handed.

The short version

A great digital menu is a real web page, not a PDF and not a photo of a card. Gather your dishes, prices, and one honest line each, prompt an AI model for a single self-contained page built phone-first, and organize the sections so people order more. Art-direct it until it feels like your room, add the tags and sold-out states that save your staff time, then publish it once and point a QR code at the link. Change the menu whenever the kitchen does, and never reprint that code again.