A clinic website
with a real booking
system behind it.

Most clinic websites are brochures with a contact form bolted on. The receptionist retypes every enquiry into a paper diary, double bookings happen, and no-shows are chased by hand. The brief here was the opposite: build the thing a clinic would actually run on, and make it look like a brand worth trusting with someone’s face.

That means two problems, not one. A premium editorial front end that does not look like a template, and a booking system whose guarantees hold up when two people click the last slot at the same moment.

The brand is NACRE — mother-of-pearl. It was chosen because nacre is exactly what a good ceramist imitates when layering a veneer: translucency built in depth rather than a flat white surface. The identity follows from that idea rather than being decoration applied on top of it.

Porcelain ground, ink text, one brass accent and one deep jade. A variable serif (Fraunces) for display, Inter for interface. Numbered sections, hairline rules, generous white space, and a single motion primitive — one entrance, one easing curve, one distance — reused everywhere so the page feels composed rather than animated.

A working diary rather than a chart gallery. Views for today, upcoming, awaiting confirmation, past and everything; search across name, phone, email and reference; filters by status and clinician; day-by-day navigation. Each row expands to full patient and booking detail with the actions a receptionist actually performs: confirm, reschedule, mark completed, mark no-show, cancel.

Four figures sit at the top, each of which changes a decision: how full today is, the week’s load in chair hours, what is unconfirmed, and the month’s cancellation rate. Popular treatments and per-clinician load are shown as plain bars. Nothing is graphed for the sake of it.

A MessagingProvider interface with one operation and four message kinds: confirmation, reminder, reschedule and cancellation. Because business-initiated messages outside the 24-hour service window must use an approved template, the live implementation always sends a template — the name comes from configuration and the ordered body parameters come from the same builder that renders the demo preview.

Every message contains the patient name, treatment, clinician, date, time and booking reference. Credentials live in environment variables read only on the server; no token, app secret or API key is ever exposed to the browser bundle.

Mobile is designed, not shrunk. The progress rail becomes a compact bar with a progress line; the calendar keeps full-size touch targets; before/after runs on pointer events so mouse, pen and touch share one path, with vertical scrolling preserved through touch-action; the dashboard collapses its clinician column and moves detail into an expanding panel.

The 3D object never loads on phones at all — narrow viewports, reduced-motion users, low-core devices and data-saver connections get a hand-drawn SVG fallback that is the design on those devices, not a placeholder.