Demonstration build
Juniper Table
Juniper Table is a made-up business we built to demonstrate the work. The site is live and you can try it. The numbers shown on it are illustrative sample data.

The problem
Juniper Table is a candlelit bistro that took every reservation over the phone, which meant the host was juggling the dining room and a ringing line at the exact moments dinner service got busiest, and a guest calling during the Thursday rush might not get through at all.
What we built
A dark, typographic bistro site with a mobile-first reservation flow: party size, date, a half-hour dinner-service slot, contact details, confirmation with a stable JT- reference code. Table availability comes from a deterministic slot table rather than a live POS integration, and the kitchen's Monday closure and large-party seating limits are both enforced in that same data layer.
Decisions & why
Large-party availability as a strict subset of standard availability, not a separate 'call us' path.
A table for eight is a different constraint than a table for two. Parties over six only see slots that also clear a second, stricter check, so the site can never offer a big group a slot the floor has no room to seat.
Monday closure enforced in the slot function itself, not just a banner.
A closed-Monday notice on the page is easy to forget to update. Asking the data layer directly, no slots exist for a Monday date, period, means the reservation flow can't drift out of sync with the kitchen's actual schedule.
Half-hour dinner-service windows only (5:30 to 9:30 PM), no all-day booking grid.
Juniper Table doesn't serve lunch reservations through this flow, and a guest picking a table doesn't need to see hours the kitchen isn't even open. The window matches how the floor turns tables.
Deterministic, hash-seeded table availability instead of a live reservation-system integration.
The demo needs to behave the same way every time it's shown. The seating rules live in the code you can read, not inside a booking platform you'd have to take on faith.
The result it aims for
The build aims to let a guest land a table in the same visit that brought them to the site, so the host stops splitting attention between the dining room and a ringing phone during peak service.
This is the goal the build is designed to hit, not a measured client outcome.