Easy Driving School: a booking engine that cannot double-book a car

Easy Driving School runs SAAQ road-test preparation from three centres across Greater Montréal — Laval, Kirkland and Henri-Bourassa — and has taught more than 1,100 students since 2015. Bookings arrived by phone, by text and in person, and were reconciled by hand against instructor availability and a small fleet of dual-control vehicles.

A driving lesson is a harder scheduling object than it looks. Every booking has to hold together a student, a service, a centre, a time window, an instructor and a specific car. Any one of those can change at short notice, and getting it wrong means a student arrives for a road-test rental and the car is not there.

The hardest requirement was concurrency. Two people booking the last slot at the same centre at the same moment must not both succeed. On a serverless platform, where requests are handled by many isolated workers, "check then write" is a race condition waiting for a busy Saturday.

The second constraint was the instructors. They already ran their working lives out of Google Calendar and had no interest in a second system to maintain. Any solution that required them to keep availability in two places would have been abandoned within a month, and the schedule would have gone back to being wrong.

The third was the students. They are mostly teenagers and newcomers booking a handful of lessons. Anything requiring an account, a password and a confirmation email loses a meaningful share of them at exactly the point where they were ready to pay.

And in Québec, bilingual operation is not optional, while Law 25 sets real expectations about how personal information — including minors’ — is collected and retained.

A public booking flow that works without an account. A student picks a centre and a service and books; a link can preselect both, so the school can send someone straight to the right form from an ad or a text message. Bookings are managed afterwards through a hashed, single-purpose token rather than a login.

An availability engine that understands the real domain: centres, services, pooled capacity where any qualified instructor will do, and named resources where a specific car or person is required. Buffers, overrides and blackout periods are all first-class rather than bolted on.

A booking lock implemented as one Durable Object per centre per local date. Final capacity checks for a given day at a given centre are serialised through a single coordinator, which makes double-booking structurally impossible rather than merely unlikely.

Google Calendar integration through OAuth, calendar listing, FreeBusy queries and event creation. Instructors keep managing their availability where they already live; the system reads their real busy state and writes a canonical invitation for the student plus internal blocking events for the instructor and the vehicle.

An admin portal built for a phone, because the owner is rarely at a desk: a Today view, the booking list, emergency controls for a car breaking down or an instructor calling in sick, plus management of centres, services, resources, forms and retention.

Revenue analytics for the owners — a revenue report and a pivot that can be cut by service, centre, instructor, package, weekday or month, with a trend line, goal tracking, CSV export, and drill-down from any figure back to the bookings that produced it. It is access-controlled: revenue is visible to owners and admins, not to staff.

A public bilingual marketing website as a separate static application, reading live centre, service, package and availability data from the booking API rather than duplicating it.

No student accounts. The single most consequential decision on the project. Accounts would have made several features easier to build and would have cost the school bookings. Management by hashed token gives the student everything they need — reschedule, cancel, view — with nothing to remember and no password to reset.

Serialise the capacity check, not the whole booking. Locking broadly would have made the system feel slow at exactly the moments it is busiest. Narrowing the lock to one centre for one local date keeps the guarantee where correctness actually matters and leaves everything else concurrent.

Meet instructors in Google Calendar. We could have built a better availability interface than Google Calendar. It would not have been used. Reading FreeBusy from the calendar they already maintain means the schedule reflects reality without asking anyone to change how they work — the same reasoning that put WhatsApp at the centre of NextiaDriveOps.

Anonymise for privacy, aggregate for analytics. A daily retention job strips personal information from historical bookings while preserving the dimensions the revenue reports are built on. The school keeps its year-over-year analysis; the records stop holding a teenager’s phone number long after the lesson happened. Treating retention as a design input rather than a compliance chore is what makes both possible.

A deliberately narrow first release. No student accounts, no learner-progress tracking, no payments, no CRM, no messaging automation, no AI. Each was discussed and each was excluded, because a booking system that is correct and in use beats a platform that is still being built.

The booking platform and the public site are both in production, bilingual throughout, running on Cloudflare Workers with D1 and Durable Objects. The availability rules — resource requirements, overrides, buffers, busy calendars, serialised capacity, form handling and retention — are covered by an automated test suite, because scheduling logic is exactly the kind of code that breaks quietly.

The transferable part is the pattern rather than the domain: a capacity-constrained booking problem, a workforce that will not adopt a second tool, a customer base that will not create accounts, and an owner who needs to see revenue by dimension. That describes a large share of appointment-based businesses.