Scheduling software is a concurrency problem with a calendar on top
Appointments, classes, resources, technicians, rooms. It looks like forms and a calendar view, and underneath it is the one domain where two users pressing the same button at the same time has to produce exactly one booking - and where an AI builder's generated code reliably produces two.
- Two customers have been booked into the same slot.
- Your customers and your staff are in different timezones.
- A booking is worth money, so a no-show or a cancellation has a policy attached.
- Availability depends on more than one thing - a person and a room, or a technician and a van.
- Staff keep their real calendar somewhere else and copy it across by hand.
Where a generated prototype stops being enough
Not general advice. These are the failures specific to this kind of product, and none of them are visible on screen.
- 01
Check-then-insert is a race, and it is what gets generated
Read availability, decide the slot is free, insert the booking. Between the read and the write another request does the same thing.
- 02
Daylight saving breaks bookings twice a year, in advance
An appointment stored as a local wall-clock time shifts by an hour when the offset changes.
- 03
Availability is a constraint problem, not a query
The slot needs a technician who is qualified, a vehicle that is free, travel time from the previous job, a lunch break and business hours.
- 04
Money makes cancellation a policy, not a delete
Deposits, no-show fees, refund windows, rescheduling limits. Each is a rule with a monetary consequence, and "the customer cancelled" is a different event from "the booking was deleted" - one has an audit trail and a refund attached.
The sentences we hear most, and what we do about each one
"Two people booked the same slot and I had to apologise"
It happens under load, which means it happens on your best day.
How we helpThe constraint moves into the database, where it belongs - an exclusion constraint or a unique index on the resource and time range, so the second write fails rather than succeeding.
"The times are wrong for my overseas customers"
Everything displays correctly in your timezone and is off by hours for someone else, or shifts by an hour after a clock change.
How we helpInstants stored in UTC, the booking's timezone stored alongside it, recurring series stored as local rules and expanded per occurrence, and every display converted explicitly.
"My staff keep their real calendar in Google"
Availability in the app disagrees with reality because the person's actual calendar lives elsewhere.
How we helpTwo-way calendar sync with the busy blocks from their real calendar treated as authoritative, and bookings pushed back as events.
"No-shows are costing me and I cannot enforce anything"
There is no deposit, no card on file, no policy encoded anywhere - just a message asking people to please turn up.
How we helpPayment holds or deposits at booking, a cancellation window encoded as a rule rather than as text on a page, automatic reminders at the intervals that actually reduce no-shows, and a record of what was charged and why when a policy is applied.
The parts that make it hold
Double-booking impossible at the database
An exclusion constraint on resource and time range. The second concurrent write fails; the application handles it.
Timezone and recurrence done properly
UTC instants with a stored zone, recurring rules expanded per occurrence, tested across a daylight-saving transition.
Multi-constraint availability
Person, resource, travel time, working hours and buffers solved together rather than one at a time.
Calendar sync
Two-way with Google and Microsoft, treating external busy blocks as authoritative and surfacing conflicts.
Reminders and notifications
Email and SMS at intervals chosen to reduce no-shows, with delivery tracked so a missed appointment has a record.
Payments and policy
Deposits or card holds, cancellation windows encoded as rules, refunds with an audit trail.
Usually connected to
- Calendars: Google Calendar, Microsoft 365
- Payments: Stripe, including holds and deposits
- SMS and email: Twilio, Resend, Postmark
- Video: Zoom, Google Meet, Teams links on booking
- Maps and routing where travel time is a constraint
- Your CRM or accounting system
In the order it actually happens
Growth does not break everything at once. For this kind of product it breaks these four things, in this sequence, and each one is cheap to fix before it happens.
| At | What breaks | becomes | The fix |
|---|---|---|---|
| Any concurrency at all | Check-then-insert allows a double booking | Database exclusion constraint on resource and time range | |
| First customer in another timezone | Times and reminders display and fire wrong | UTC instants with a stored zone; recurrence expanded per occurrence | |
| Second constraint on a slot | Physically impossible schedules get accepted | Availability solved across all constraints, including travel and buffers | |
| Money on the booking | Cancellations have no policy and no audit trail | Deposits or holds, encoded policy, recorded charges and refunds |
Four phases, each ending in something you keep
The first one is free. Scope is fixed after it, and you keep the findings whatever you decide next.
- 013–5 days
Correctness review
Free. We load-test the booking path concurrently and try to create a double booking - which, in generated scheduling code, usually succeeds.
You receive
- Concurrency test results, with a reproduction if we succeed
- Timezone and recurrence audit
- Availability constraint review
- Ranked plan with effort estimates
- 021–2 weeks
Make double-booking impossible
The constraint moves into the database and the application learns to handle a rejected write.
You receive
- Exclusion constraint on resource and time range
- Graceful handling of contended slots
- Concurrency test in CI
- 032–3 weeks
Time, availability and sync
Timezone and recurrence corrected, multi-constraint availability implemented, calendar sync connected.
You receive
- UTC instants with stored zones; recurrence per occurrence
- Availability across people, resources, travel and buffers
- Two-way Google and Microsoft calendar sync
- Tests across a daylight-saving transition
- 041–2 weeks, plus 30 days support
Money, reminders, hand over
Deposits and cancellation policy encoded, reminders wired up with delivery tracking, monitoring and documentation.
You receive
- Deposits or card holds with refund audit trail
- Cancellation policy as rules, not as page copy
- Reminders with delivery tracking
- 30 days of post-launch support
Before you book the call
Because two requests can both check, both find the slot free, and both insert.
If your booking is one person and one slot, yes - they are excellent and far cheaper than building.
By generating it deliberately: many parallel requests for the same slot, in CI, asserting exactly one succeeds.
Related solutions
Field service management
Dispatch, job tracking and a technician app that has to work in a basement.
See what breaksBusiness internal tools
The admin panel, ops console or back office that the business now depends on.
See what breaksCustomer portals
Where your customers log in to see their own data - and only their own.
See what breaks
Building booking and scheduling?
The first review is free, and it ends with a straight answer - including when the answer is to buy something off the shelf instead.