Studies

Marlow

Salon booking where the free times are actually computed — staff hours, service length and the diary already taken.

The Marlow booking screen: a row of dates above a grid of available start times, each labelled with the stylist who is free.

The brief

Booking is the most commonly commissioned piece of software a small business ever buys, and it was the one thing this portfolio could not show. Anchorpoint simulates a marketplace booking; nothing showed a single business managing its own diary — its staff, its opening hours, its cancellations.

So this is a salon: three stylists, four services of very different lengths, and a fortnight of availability that has to be worked out rather than asserted.

The constraints

  • A slot is a claim, and a wrong claim is expensive. Offering a time that is not really free means two people in one chair and a conversation nobody wants to have.
  • Services are not the same length. Forty-five minutes for a cut, one hundred and sixty-five for a colour and cut. A grid of hourly slots would be a lie.
  • Staff are not interchangeable. One stylist does not colour. Another works four days. Availability is per person, not per salon.
  • The person booking is on a phone, at night, deciding in under a minute.

The decisions

Availability is computed, never listed

A start time is offered only when the whole service fits inside one stylist's working block for that weekday and overlaps nothing already in the diary. Overlap is the half-open interval test — two appointments clash when each begins before the other ends — evaluated per stylist, at fifteen-minute granularity.

The visible consequence is that a forty-five minute cut has ten of the next fourteen days available and a colour-and-cut has four. That fall-off is the system telling the truth about a small salon's diary, and it is the entire reason the screen is worth building rather than mocking up.

What it costs: the grid has to be recomputed on every change of service, stylist or date. That is cheap here and would be a cached query against real data; either way it beats storing availability and keeping it in step.

The check runs again at the moment of booking

The slot was free when the grid was drawn. That is not the same as being free now — somebody else may have taken it while the form was being filled in. Confirming re-runs the same availability function and refuses if the time has gone, sending the visitor back to the grid with the reason.

In this build both checks are in one browser, so the race cannot actually happen. It is written anyway, in the place it belongs, because the version of this that talks to a server needs exactly that check on exactly that line.

What it costs: a second computation on submit. It is the difference between a booking form and a booking system.

Cancellation is a window, not a button

An appointment more than twenty-four hours away can be cancelled outright. Inside that window the button is gone and the reason is stated — call the salon. A no-show costs a chair; a cancellation an hour before costs the same chair and takes the slot out of circulation too late for anyone else.

What it costs: some late cancellations become phone calls. That is the point: the ones that need a human get one.

The seeded diary is half full, deliberately

The first version filled each stylist's day from opening with a coin-flip per slot, which packed the day almost solid — and a colour-and-cut then fitted on exactly one day in fourteen. The screen read as broken rather than busy.

It now places two to four appointments per stylist per day at random valid starts, rejecting collisions. Around half the day is booked and the long contiguous blocks a colour needs still exist. A booking demo where everything is free proves nothing; one where nothing fits proves the wrong thing.

What it costs: nothing, except noticing. This was found by walking the flow rather than by reading the code.

The front desk sees the same data from the other side

A third screen shows the day laid out per stylist, with each appointment's span, service and customer — the view the salon actually lives in. It reads from the same store as the booking flow, so a booking made on the phone appears in the diary immediately, marked as yours.

What it costs: a second interface to maintain. Without it this is a form that sends an email, and the business still runs on a paper book.

Built with

  • Vanilla HTML, CSS & JS
  • No framework
  • No build step
  • localStorage
  • Cloudflare Pages

Everything runs in the browser: no accounts, no network, no payment. The Reset the demo link in the footer puts the diary back to how it started. A real deployment would move the same availability function to the server, where it becomes the authority rather than a courtesy.

This one is served from the portfolio's own Pages project as a subdirectory rather than as a separate site — which is worth knowing, because it means adding a demo now costs a folder rather than a new project, a new hostname and another pages.dev address.