A diner that has to answer one question fast
A diner's guests decide in the time it takes to find a menu. Metropolitan's answers — the menu, the hours, the way there — sit one tap from a search result, in German first and English beside it.
What the owner actually opens: pageviews, unique visitors, dish lookups and conversions, on the day they happened. Where a visit becomes something — a job application or a reservation call — read back next to where the traffic came from. Every string on the site as one row, German and English side by side, editable without a developer. A dining-room photo replaced from the same screen, with alt text required in both languages before it saves.
- Client
- Sector
- Hospitality
- Market
Germany - Delivered
- 2026
Metropolitan sits on Kollwitzstraße in Esslingen am Neckar, a minute from the S-Bahn and inside the DICK-Areal next to the Traumpalast cinema. American diner cooking and a brasserie in the same room, with Swabian dishes on the same menu and a bar and billiards behind it.
We built the website.
The only question that matters
Almost nobody reads a restaurant website. They check it, usually on a phone, usually while deciding whether to walk there, and usually with one question: is this place open, and is it the kind of evening I am after.
So the job is not to describe a restaurant. It is to answer that question in the first screen, and then to stay out of the way. Hours that are current. A menu you can actually read on a phone rather than a PDF that opens at 10% zoom. A phone number that dials when you touch it.
What a diner has to communicate that a menu cannot
The room is the product here as much as the food is. A cinema next door and a billiard table change who arrives and when, and a site that reads like every other restaurant template will bring the wrong crowd on the wrong night.
The detail that goes on the page is chosen for that: the lunch service, the late kitchen at the weekend, the fact that a dog is welcome and the room is step-free. Those are the things that decide a booking, and they are usually the things buried three clicks down.
Allergens, treated as a safety requirement
German law requires every dish to state which of the fourteen EU-regulated allergens it contains, and getting this wrong is not a formatting slip — it is the kind of mistake that puts someone in a hospital. Every dish on the menu is checked against all fourteen categories, a guest can filter a dish out by allergen or filter the whole menu down to "vegetarian" before ordering, and German and English stay in step so a visitor reads the same warning a local does.
The kitchen gets the same data as a printable A4 sheet, generated on demand and correct the moment it prints, to keep near the pass rather than trust to memory.
The admin side, built for the people who actually run the room
The allergen list above is a grid in the admin, not a form: every dish against all fourteen allergens, tick a box, save, and the public menu and the printed sheet are both current in the same motion — no developer, no ticket, no waiting for the next release.
The rest of the site is edited the same way. Every string on it — the homepage quote, an event description, a lunch-strip label — sits in one bilingual editor, German on one side and English on the other, so nothing ships in one language while the other waits. A dashboard alongside it shows what a visit actually becomes: which dish gets the most attention, when the room is busiest, and how often a visit turns into a job application or a reservation call.
On this page
What would yours have to do?
Thirty minutes with the engineer who would build it, not a salesperson. Straight answers on scope, on cost, and on where the real risk sits.