Slatewell

The problem domain

Service-business booking looks simple from the outside: pick a service, pick a time, done. Underneath it is one of the harder small-business engineering problems. Staff have different capabilities. Services have different durations and different buffer times around them. A single calendar has weekly recurring availability, lunch splits, vacation blocks, same-day lead time, and a cancellation window. Two customers can land on the same slot a millisecond apart and exactly one of them gets the booking. The off-the-shelf options either solve one of those well and the rest poorly, or they solve all of them but only inside an enterprise contract.

What we built

A complete booking and scheduling platform over a synthetic med-spa: one business, eight services, five practitioners with a capability matrix, Tuesday through Saturday availability with lunch splits and time off, 120 customers, and 300 historical and upcoming bookings that respect every constraint above. A deterministic seed makes every demo run reproducible, and an integrity gate (ten checks: no staff double-booking, capability match, closed-day exclusion, deposit-state consistency, and more) refuses to ship a database that violates them.

The stack is Next.js 14, TypeScript, SQLite, and Tailwind v4, served from a single standalone container behind Cloudflare. The database is baked into the image at build time, matching the rest of the demo fleet's posture. The booking page is mobile-first by default; the same wizard works on a 390-pixel phone and a 1440-pixel desktop.

Scheduling integrity

The heart of the platform is a pure slot engine: a small, dependency-free module that takes a service, a staff member (or the First Available auto-assign), a date, and the working calendar, and returns the set of bookable starting times. It knows about service-level buffers that occupy staff time without lengthening the customer's appointment, about same-day lead time so the next slot is never five minutes from now, and about staff capability so a customer never sees a slot with a practitioner who cannot perform the service.

Because the engine is pure, it tests as a unit (twelve checks covering the edge cases that bite real installations: lunch gaps, back-to-back services with buffer overlap, time-off windows, capability mismatches). Because it is the same engine the seed used to lay down 300 bookings without conflicts, the demo data is its own end-to-end test.

The last mile is the write path. The customer-facing API re-validates the chosen slot inside the same SQLite transaction that inserts the booking. A race to the same minute resolves to exactly one winner; the loser gets a 409 and a fresh availability fetch, not a corrupted calendar.

The production path

A real deployment swaps SQLite for the operator's database, mock SMS and email senders for a transactional provider, and the demo's deposit hold for Stripe (or whatever the merchant already runs). The slot engine, the typed data layer, the transaction-safe write path, the wizard UX, and the admin surfaces underneath them do not change. The discipline that makes the demo refuse to double-book is the same discipline a production booking system has to inherit on day one, or it will be rebuilt under a deadline later.