Booking and appointment system

What this actually solves

Somebody in the business is spending a large part of every day answering the same question on the phone. Is four o'clock tomorrow free. What about Thursday. That time is not free just because nobody invoices for it, and it is being spent by the person you probably most want doing something else.

Underneath that are two costs that are easier to measure. The first is double booking — two people written into the same slot because two staff members were looking at the diary at once, and one of them arrives to find somebody already in the chair. The second is no-shows. People do not skip appointments out of malice; they forget, because they booked nine days ago and nothing reminded them. For a clinic or a salon, a couple of empty slots a day is not an inconvenience, it is a permanently missing chunk of the month's revenue, and a reminder sent the day before recovers most of it.

The thing owners consistently underestimate is how many rules their business actually runs on. Every appointment has a duration, and often a gap afterwards for notes or cleaning. There is a limit on how close to the appointment somebody can still book, and how far ahead they can book at all. There is a cancellation window. There are holidays and half-days. When there is more than one practitioner, all of those exist separately for each of them. Nobody has ever written this down, because everyone in the building already knows it, and that unwritten knowledge is the thing that has to be captured before a single screen is designed.

What we do, and in what order

1. Get the rules out of people's heads and onto paper. Session lengths, buffers between appointments, capacity per slot, opening hours per person, holidays, minimum notice, maximum booking horizon, cancellation window, and whether a deposit is taken. Also the awkward ones — what happens when a practitioner goes off sick with a full day booked. This is a conversation, not a form, and it takes longer than clients expect because half the answers do not exist yet. One to two days.
2. Decide honestly whether this should be built at all. With the rules written down, it is usually obvious whether a hosted tool embedded into the site covers it, or whether the combination of staff, services and payment rules needs a real build. On WordPress that decision is often between a plugin such as Amelia or Bookly and a custom build. We would rather lose the larger job than sell it to someone who did not need it. Half a day.
3. Design the data and the time handling before any interface. How availability is worked out — computed from working hours and existing bookings on each request, or materialised into a table of slots — is a real decision with real consequences at scale, and it gets made deliberately. Every timestamp is stored in UTC and converted for display, never stored as local wall-clock time. The uniqueness rule that prevents double booking is defined here, at the database level, not left to application code. Two to three days.
4. Build the booking flow, then the admin side. The customer journey first — pick a service, see genuine availability, choose a slot, pay a deposit if one is taken, receive a confirmation. Then the side the business lives in — the diary, manual bookings taken over the phone, reschedules, cancellations, blocked-out dates and staff management. The admin side is usually the larger half and is routinely under-scoped. One to two weeks.
5. Wire up confirmations and reminders, then test the edge cases deliberately. Booking confirmation, a reminder before the appointment, cancellation and reschedule notices. Then the tests that matter — two bookings fired at the same slot simultaneously, a booking made from a different time zone, a practitioner blocked out after bookings exist, a payment that fails halfway. Each one is exercised rather than assumed. Three to five days.

Typical stack for a custom build — Next.js on the front, Supabase or Postgres holding the bookings and enforcing the uniqueness rule, Stripe for deposits, Resend for transactional email, and a WhatsApp or SMS provider where reminders need to actually be read.

What moves the price

The range is $600–$4,000 over 2–4 weeks, and three factors decide where you land.

How many people and places. One practitioner in one location with one service length is the bottom of the range. Several staff, each with their own hours, days off and set of services, is a different system — availability has to be resolved per person, and the admin interface has to let a receptionist manage all of them.

Whether money is involved. Adding deposits, refunds, and a no-show policy brings payment handling, refund rules and failure cases with it, and it moves the price substantially. It is usually worth it, because it is the mechanism that pays for the system, but it should be a decision rather than an assumption.

Whether it stands alone or connects to things. Pushing appointments into the team's existing calendars, syncing with practice management software, or writing customers into a CRM each add integration work and each add a system whose downtime is now your problem too.

What usually goes wrong

Times are stored as local wall-clock values. Everything looks correct while the owner, the staff and the customers are all in one city. Then the owner takes bookings from Dubai, or a customer books from London, or the clocks change — and appointments land an hour or five hours off, with two people confidently holding different times for the same meeting. There is no clean fix after the fact, because the stored data no longer says what it meant. Store UTC, convert on display, and the whole class of failure disappears.

Double booking is prevented only in application code. The code checks whether the slot is free, finds that it is, and writes the booking. Two customers tapping the same popular slot within the same second both pass that check, and both get a confirmation email. It is rare enough to survive testing and common enough to happen in the first busy week. The protection has to be a constraint the database enforces, so the second write fails and that customer is shown the next free time instead.

Staff absence is treated as an afterthought. The system is built assuming the working hours in the specification are the working hours forever. Then somebody is off sick with six appointments booked, and there is no way to block the day that also surfaces the existing bookings, move or cancel them, and tell those customers. So it gets done by hand, badly, over the phone — which is precisely the work the system was bought to remove.