A restaurant that owns its own bookings

The problem

Bookings arrived two ways, and neither of them was good. The first was the phone, which rings hardest at exactly the moment the room is fullest: someone leaves the pass, finds a pen, writes a name on a piece of paper and hopes it survives the shift. The second was a booking platform, which charged a commission on every cover it sent through — including the regulars who would have walked in anyway.

The second cost is the one that is easy to miss. A platform that takes the booking also keeps the guest. The restaurant was paying per head to rent access to its own customers, and after years of service it had no list of its own to show for it.

The approach

A five-step reservation flow on the restaurant's own site: date, then time slot, then seating preference, then guest details, then confirmation. Five short steps rather than one long form, because each step asks for a single decision — and a guest who changes their mind at step two does not have to retype a phone number.

The data sits in Supabase, with an admin view for the floor team. That view took the most care of anything in the build: it is used standing up, on a phone, in the middle of service, by someone who has about four seconds. It shows tonight's covers and lets a booking be moved or cancelled in one tap. Everything else on it is secondary and looks it.

Opening hours and ratings are read live from Google Places rather than typed into the page. Small decision, long tail: nobody has to remember to edit the site when the hours change over Christmas, and the rating a guest sees on the page is the rating they see on the map.

The site itself is plain HTML with Tailwind and a handful of small vanilla-JS components — no framework, no build step. That was a handover decision rather than a technical preference. A menu changes more often than anything else on a restaurant site, and changing one should not require a deployment, a developer, or waiting until Tuesday.

The outcome

Live, and running as a full multi-page site — menu, events, reservations, contact and the legal pages — with structured data throughout and an installable PWA wrapper for guests who come back often.

Commission per cover is now zero on every booking the restaurant sources itself, and the guest list belongs to the restaurant. The component structure was kept deliberately ordinary so that handover meant handover: no retainer, and no dependency on whether I happen to be available.

I also keep the books for this business, which shaped the build in ways that would not be obvious from outside. Knowing how card settlements land against POS reports at the end of the month is what stops a payments integration from quietly corrupting the VAT position behind it. It is the one project here where both halves of the practice point at the same client.