Tutorials / Intermediate+

Build a Booking System With AI (Appointments Without the Monthly Fee)

Tutors, barbers, consultants, photographers: a booking page where clients pick a real open slot, plus the admin view where you control availability — and the double-booking problem solved properly.

DifficultyIntermediate+

TimeA weekend

You'll needClaude · Free Supabase account · A service people book you for

You'll buildA two-sided system: a public page showing your genuine availability where clients book and get confirmation, and a private admin page where you set hours, block dates, and see your schedule.

Scheduling tools charge $10–20/month forever for what is, underneath, a calendar table and one hard rule: never sell the same slot twice. The build teaches more real engineering than anything else at this difficulty — time zones, conflicting writes, two-sided interfaces — which is exactly why booking links impress clients and why this tutorial is ranked Intermediate+. Worth it: when you finish, you own your scheduling.

Step 1 — Define your availability rules in English

Write yours down precisely; ambiguity here becomes bugs later: appointment length (and one length or several?); working hours per weekday; buffer between appointments; how far ahead bookings open and close ('not within 12 hours, not beyond 30 days'); blocked dates. Then have Claude design the schema around it: an availability_rules table (your weekly template), blocked_dates, and bookings (slot start, client name/email/phone, service, status, a cancellation token). Slots aren't stored — they're COMPUTED: rules minus blocks minus existing bookings. That one design decision is what keeps the system simple.

Step 2 — The public booking page

Build the client-facing booking page as a single HTML file (supabase-js from CDN; schema below). Flow: pick a service [list, with durations]; a week-view calendar computing open slots from my rules minus blocked dates minus confirmed bookings; tapping a slot opens a form (name, email, phone, notes); on submit, create the booking and show a confirmation screen with the details and a cancellation link built from the booking's token. Times displayed in MY timezone [America/New_York], labeled clearly. Mobile-first — most clients book from phones. Warm, trustworthy design. Complete file. [paste schema]

Step 3 — Kill the double-booking properly

Here's the trap hiding in the happy path: two clients open the page, both see Tuesday 2:00 free, both submit. Checking availability in JavaScript before inserting does NOT fix this — both checks pass before either insert lands. The database must be the referee:

Prevent double-booking at the database level: add a unique constraint on the booking slot (give me the SQL), so the second simultaneous insert FAILS rather than duplicating. Then update the booking page to catch that specific failure and tell the client 'that slot was just taken — here are the nearest alternatives' and refresh the calendar. Explain in comments why a client-side availability check alone can't solve this.

Worth knowingTest it for real: the same slot open in two browsers, submit both within a second. One confirmation, one graceful 'just taken' — that's the system working. This race-condition lesson, by the way, is the same reason ticket sites and e-commerce inventories live or die; you just learned it on a barbershop calendar.

Step 4 — Your side of the counter

The admin page (auth-protected via the accounts tutorial, or a local-only file like the wedding tutorial's dashboard): today/week schedule view, edit weekly hours, block dates with one tap, cancel/reschedule bookings, and a manual 'book for a phone client' form that respects the same constraint. Then notifications, the cheap way first: the Telegram-bot pattern pinging you on each new booking costs nothing; client confirmation/reminder emails via a transactional email API are the polish that meaningfully cuts no-shows — ask Claude to wire your provider's free tier.

Step 5 — RLS for a system with two publics

The policies are subtler than usual and worth stating: anonymous visitors may INSERT bookings and may READ bookings only enough to compute busy slots — but must never read other clients' names or contact details. Ask for exactly that (a view exposing only slot times is the clean trick), plus owner-only full access. Then run the AI-code-safety review; a table of clients' phone numbers is precisely the kind of thing that leaks from vibe-coded apps.

What you can charge for now

Add a deposit via Stripe Payment Links at confirmation (that tutorial chains right in) and you've matched the paid schedulers' core feature set. And notice what you're holding: a niche booking system molded to one trade is a sellable product — '[your trade] booking template' — which is the validation tutorial's cue, not this one's.

Keep going

Need somewhere to put it live? See where to host AI-built sites. Compare tool costs on the pricing tracker (or stick to the free options), then pick your next build.