The problem this tests
Centres like this live on their calendar, but their websites rarely touch it. The site lists services and a phone number; the booking happens in WhatsApp, in a notebook, or in a third-party tool the site knows nothing about. Availability is never where the visitor is.
Swan was built to test the opposite: a public site whose main object is the calendar, so that choosing a treatment and reserving a slot are the same gesture, and the centre manages what the site shows from the same place it manages its day.
Time as the first question
Instead of a menu of prices, the hero asks how much time you have. Treatments are laid out on a ruler by duration — a fifty-minute class, an hour of facial care, two hours of lash work — so the first filter is the one visitors already apply in their heads, and each bar leads straight into the booking with that service preselected.
The booking itself is one pass: service, professional, date, time. Slots come from published schedules, so what can be chosen is what is actually free, and a request lands with everything the centre needs to confirm it.
The operation behind the page
The panel is the other half of the product. Services, durations, professionals, working hours, exceptions, the calendar and the public content are edited by the people who run the centre, and the site reflects them without a developer in between.
That is the boundary the exercise tests: a public surface built for a stranger with a phone in one hand, and an operational tool built for a known user who needs completeness, sharing one source of truth.
What the build proves
Swan is bilingual on a single codebase with authenticated administration and a relational database underneath — the actual shape of a small service business that wants its site to do work, not just describe it.
It shows the studio designing an interface around an operational constraint — availability — and building the back office that makes that interface true.
