Case study

A booking platform the firm owns.

Scheduling looks like the easiest thing on this list. It is the one where the edge cases are most expensive, because every one of them is a client who could not book a time.

The problem

The firm rented a scheduling tool at a seat per person. It handled the common case well and could not express the firm's actual rules: that certain conversations require a qualified person, that one team member should be filled to capacity before the next is offered anything, and that some meetings need everybody free at once.

Those rules were being applied by hand, which meant they were applied inconsistently.

What was built

Double-booking is prevented by construction

Not by a check before writing. Two requests arriving in the same instant will both pass a check and both write. The database holds an exclusion constraint on the booked time range, so the second one cannot be inserted at all — the guarantee lives below the application rather than inside it. Co-hosts are covered by the same mechanism.

Any rule enforced only in application code is a rule that holds until two people click at once.

Two failures worth passing on

Invite links expired after an hour. The rollout asked people to get set up that week, so most links were dead long before they were clicked — and the self-serve recovery path was rate-limited to two emails an hour across the entire project, so a queue of people requesting new links would have had two succeed and the rest fail silently. Neither showed an error. It looked like broken accounts.

The second: a reschedule link sits in every confirmation and reminder email ever sent, so people arrive on it long after the booking is gone. It used to answer with a page-not-found. A URL you have put in someone's inbox is permanent, and it has to still explain itself years later.