A restaurant website built for someone standing outside, hungry.
A restaurant site has one job and about eight seconds to do it: show what is on the menu, what it costs, whether you are open and how to get a table. It is looked at on a phone, one-handed, often on mobile data outside your door. Everything that does not serve that moment is decoration you are paying for.
View evidenceThe menu as text, not as a PDF
A PDF menu is the most common and most expensive mistake in this trade. It downloads instead of opening, renders at unreadable size on a phone, cannot be searched, and is invisible to Google — so the dish someone is actually googling never leads to you. Written as real pages, the menu is readable in one tap, changeable in a minute, and eligible to appear in search results and on your Google Business Profile.
Allergens without a legal headache
Austrian law requires the fourteen allergen groups to be declared, and doing it as a footnote nobody can map to a dish satisfies nobody — least of all the guest with a real allergy who then does not book. Each dish carries its own codes, kept in the same place you edit prices, so updating a recipe updates the declaration instead of leaving the two to drift apart.
Reservations where you already take them
If you run OpenTable, Quandoo, resmio or a table book by phone, the site sends people into that — one obvious button, working on a phone, no second system to check at service. Nobody needs another inbox during a Friday dinner rush. If you take reservations by phone only, the number is a tap-to-call, which on a phone is the whole feature.
Photographs that load before they are scrolled past
In this trade the pictures are the argument, and they are also what makes most restaurant sites unusable on mobile data. Images are served in modern formats at the size the device actually needs, so a gallery that used to weigh eight megabytes weighs a few hundred kilobytes and appears immediately. The food still looks like the food.
Found by the dish, not just by the name
People who already know your name will find you anyway. The traffic worth having comes from someone searching for a dish and a district, or looking at Google Maps at half past seven. That means a Google Business Profile that agrees with the site, restaurant and menu structured data, the district in the copy, and hours that are correct on the days everyone else forgets to update.
from landing on the site to reading the menu
largest contentful paint, measured on this site
PDFs between a guest and a price
The logic behind the work.
Can we change the menu ourselves?
Yes — that is the point of not using a PDF. Dishes, prices and allergen codes live in one editable list, and a change is live in minutes without a designer. If you change the menu daily or seasonally, say so before the build and the editing side is designed around that rhythm rather than bolted on.
Do we need a delivery or ordering system?
Usually not on your own site. Lieferando and its competitors already own that search, and building a parallel ordering flow rarely pays for itself for a single location. What does pay is being unmistakably findable and reservable, plus a clean link to whatever delivery platform you already use. If you want to take orders directly to avoid the commission, that is a shop project and is quoted as one.
We have good photos already. Does that save time?
It saves the largest single delay. In this trade the photographs are most of the persuasion, and waiting on a shoot is usually what stretches a one-week build into a month. Send what you have — phone photos in good daylight are often enough to launch with, and can be replaced later without rebuilding anything.
How fast can it be live?
About a week from the point the menu and the photographs exist, because the build is static and there is no CMS to configure. A single-page site with the menu, hours, address and a reservation link can go live in two to four days if you need something standing before a weekend.