The Residence

// what it is

A booking platform for AAAM Residency, an invented letting brand with two properties — one of them The Elmstead, a fictional house in Hampstead. The brief I set myself was to build the whole path a guest actually takes — browse, check dates, pay, get looked after — rather than a landing page with a form bolted on.

// the problem

Most booking demos stop at a pretty calendar. The hard parts are the ones a real operator would hit on day one: two people trying to book the same week, a payment that succeeds while the browser dies, and a guest asking a question at 1am that nobody is awake to answer.

// decisions

1. 01

   Availability is decided by the database, not the UI

   A calendar that merely hides taken dates still lets two people through if they load it at the same moment. Overlap is checked server-side against the bookings table on submit, so the second request loses cleanly instead of producing a double booking that someone has to untangle by email.

2. 02

   Payments are treated as something that can fail halfway

   Stripe runs in test mode, but the flow is built as though it isn't: the booking is only confirmed on the payment result, not on the user reaching a success page. Closing the tab mid-checkout doesn't leave a paid-but-unrecorded stay.

3. 03

   The concierge is scoped, not a general chatbot

   An AI concierge answers guest questions against the property's own information. Keeping it narrow is the point — a chatbot that will cheerfully invent a check-in time is worse than no chatbot, so it answers from what the site actually knows.

4. 04

   An admin dashboard, because someone has to run it

   Bookings are managed through a real admin view rather than by reading the database directly. It is the least glamorous part of the build and the one that decides whether software like this survives contact with its owner.