A restaurant that answers its own email

The brief I set myself

Thirty covers, open five days, a menu that changes with the market most weeks. No reservation platform, because at this size the booking fees cost more than the problem they solve and the owner would rather reply personally.

The decision that shaped it

This is the only one of the three builds that commits to a single colour scheme instead of following the visitor's system setting. A dining room is dim. A restaurant site that flips to bright white because somebody's phone is in light mode is not expressing a brand, it is expressing a default.

So the whole palette is stated once, explicitly, and it is deep olive rather than the warm beige that arrives unbidden on every food brief. The amber is the only bright thing on the page and it marks only the menu headings and the things you can click.

The menu was the real design problem

Most restaurant sites either put the menu in a PDF, which is unreadable on a phone and invisible to search, or build it as a table, which collapses badly at narrow widths. Here each dish is a flex row with a dotted leader between the name and the price, so it reflows to any width and reads as a menu rather than a spreadsheet.

It is also plain HTML the owner can edit. Changing a price means changing a number in a file, not logging into a content system that will want updating in two years.

The allergy field is a privacy decision

A booking form with a notes box on a restaurant site will collect health information, because that is where people type their allergies. That makes it a more sensitive field than the rest of the form, so the privacy notice says specifically what happens to it: the kitchen reads it, it is used for the booking, and it is not kept afterwards.

What I would do differently

The hours are hard-coded. For a restaurant that closes for two weeks in August, the honest answer is a single file the owner edits, which is what a care plan is for, rather than pretending a static page maintains itself.