Can a restaurant owner beat a developer to shipping a digital menu?

A field test. Timestamped.

A friend of mine runs an upscale Italian place. Last week he asked me the question everyone eventually asks the person they know who codes: what's the best way to get a digital menu online, and can you help?

It's 2026 and this is still a real question. Neighbours, friends, family, somebody always needs a small thing on the web.

My honest first reaction was hesitation. Not because the job is hard. Because it's small enough that saying no feels rude, and permanent enough that I'd quietly become the maintenance contract. Every price change, every seasonal dish, every "can we make the header a bit bigger" comes back to me.

The developer version of this job is well worn: open the IDE, launch my coding agent CLI, write a plan, let it execute. Simple static HTML, a small GitHub Action, deploy to Pages. Free hosting, clean result. Call it an hour with the coffee break.

Clean, but antiquated. We're in the era of AI coding and I'm still the bottleneck in that story. So instead of doing the job, I ran a test.

The question: could the restaurant owner do this himself, with no IDE, no git and no local installs? And would he beat me?

The rules

• No local setup. No editor, no terminal, no repo.
• The prompt has to be written the way an actual restaurant owner would write it. No jargon, no stack, no architecture.
• One shot, then one round of improvements.
• Track wall-clock time and cost.

The tool is predev. Which is ours, so trust the timestamps and not my enthusiasm.

Quick tangent: why bother with a digital menu at all?

Economists have a term borrowed straight from this industry: menu cost. It's the overhead a business absorbs every time it changes a price. Not just the printing, but deciding on the new number, telling customers about it, and eating the demand you lose while they get used to it. The name comes from restaurants literally sending menus back to the printer.

A web menu doesn't remove the hard part, which is deciding what to charge. It removes everything downstream of that decision: no reprint, no reorder, no box of obsolete menus in the back room. Add a QR code and a seasonal dish goes live in the time it takes to type it.

The prompt

I tried to emulate what an actual owner would type. No technical jargon, no constraints. A result, an audience, and a workflow.

i want a page that looks and feels like a high end italian restaurant menu. i will use a qr code to link to the menu for my guests. english, german and italian language versions and a language picker to switch between them. at the top a horizontal section navbar to jump between sections (starters, mains, desserts, wine etc). important: it should look and feel (colors, fonts etc) like an actual physical menu you would hold in your hand in a high end italian restaurant

That's it. No framework named, no design system, no hosting mentioned.

What actually happened

Sign-up first, because that counts as setup: Google SSO, no credit card. Then the prompt box.

pre.dev grades the prompt for complexity before it starts. Complex builds get routed to plan mode, where the agent interviews you first about constraints, architecture and tooling, including any API keys or dependencies it will need. A menu doesn't need that conversation, so it went straight to work.

Then, in order:

Sandbox. The project gets its own cloud sandbox. This is the part that carries the whole non-technical version of this story: nothing to install, no environment, no git. The project exists in the cloud from second one.

Scaffold. Vite, TypeScript, React, config files. Unremarkable, which is the point.

Types and content. It wrote the type definitions for the menu, including the translation shape for English, German and Italian, then populated the menu with plausible content right away instead of leaving me an empty skeleton.

The translation piece is quietly the best part for the owner. No copy-pasting into Google Translate, no second tool, no separate chat window. New dish, three languages, one message.

UI. Index page, then a full set of design tokens, then components for sections, line items, header and footer. This part went by fast.

Test. Here's the good bit. It launched the dev server, took a screenshot, and drove the page with a browser agent, clicking through the language picker and the section navigation. The wine section link didn't scroll. It caught that itself, fixed it, re-ran the test, passed.

That's the moment the whole premise holds up. A restaurant owner would not have noticed a broken anchor link. He'd have found out from a guest.

Commit. All still inside its own sandbox.

Done.

Time

Started 14:15:28. Finished 14:19:08.

Three minutes forty. From an empty prompt box to a working, type-safe, tested page, with no setup at all. The architecture is sensible and the code is clean. Not bad.

Round two

The one-shot was solid, so the question became what to improve. The whole advantage of a web menu is that it isn't paper, and I wasn't using any of that yet. Start with appetite:

add a thin image (3:1) as a header to each section, alluding to what's in the section

It generated five distinct images and placed them in the right spots. Result: mobile-friendly, fast, sticky header for navigation, and a back-to-top button it added on its own that I hadn't thought to ask for.

My developer brain immediately wanted a markdown file to manage items and prices. I talked myself out of it. For this owner, chat is the CMS, and a content file just puts one small technical obstacle between him and a price change. Right interface, wrong instinct.

At that point we were actually done.

Getting it online

The project already lives in its own sandbox, so shipping means toggling it to public. It gets a subdomain on predev. You can attach a custom domain, but for a menu behind a QR code on a table, nobody is ever going to type the URL.

What it cost

19 credits for the full project. Without the images it would have been roughly half.

The pre.dev free tier gives you 20 credits a month, so this fits. Barely, and I'll be straight about that margin: one build plus one image pass is about a month's allowance. Follow-up edits are much cheaper than the initial build, so ongoing menu changes aren't the problem. But if you're iterating hard on day one, you'll want a plan.

Hosting is included and free.

Verdict

Can the restaurant owner beat the developer? Yes, and not narrowly. My path was an hour plus an open-ended support obligation. His was under five minutes, free, and he can change tomorrow's specials himself without texting me first.

So the next time somebody's uncle needs a digital menu, you have an answer that takes five minutes and costs nothing. And if you are the uncle, you don't need me at all. Just head over to pre.dev.

We live in a great time. Happy building.

P.S.: Here is the link to the digital menu.

Let Us Know Your Thoughts and Feature Requests

We want to hear from you! We are incredibly excited to see what you build and learn how you are using In-Line Media Generation to accelerate your projects. Join the conversation and share your feedback over on our X and LinkedIn pages.

About predev

pre.dev is built to provide professional engineering teams with hyper-intelligent and cost-efficient coding agents. These agents deliver scalable, self-verifying, and model-agnostic software development.

Professional software development requires agentic coding that deeply understands system architecture, mitigates technical debt, and respects your compute budget.