Ember & Olive

Restaurant websites tend to fail in the same two ways: they either look like a printed menu someone scanned in 2011, or they look expensive and make it impossible to find the opening hours. Ember & Olive was an attempt to get the atmosphere of the first kind of site and the usefulness of the second.

The brief I set myself

Build a restaurant site good enough to hand to a paying client, then make it re-skinnable so the next restaurant takes days instead of weeks. Two goals that pull against each other, bespoke design work resists templating, and templates resist feeling bespoke.

How it is put together

Everything that makes a restaurant that restaurant lives in a handful of typed data files rather than being scattered through components:

Swapping those files plus the photography produces a genuinely different-looking site without touching a single component. The design system is the reusable part; the composition is not.

The reservation problem

There is no backend in v1, and I did not want to fake one. A form that silently does nothing is worse than no form.

So the reservation flow validates client-side with react-hook-form and zod, then opens WhatsApp with the booking details pre-filled, the guest reads the message and sends it themselves. The restaurant gets the booking in the place they already check. The general enquiry form does the same thing through mailto:.

It is not clever. It works with zero infrastructure, and both forms can be swapped for a real API route or a booking platform later without changing the components.

What I would change

The photography is Unsplash placeholder work, and it shows, the layout is built for real food photography with a consistent grain and colour temperature, and stock images never quite hold that together. The first real client version of this will look noticeably better for that reason alone.

I would also revisit the menu page. It works, but it is the most conventional part of the site, and it is the page people actually spend time on.