Ask a founder what the hard part of a Zocdoc-style app is and they will usually say the search, or the payments, or the reviews. They are wrong, and it is an expensive kind of wrong. The hard part, the part that decides whether the whole app feels magic or broken, is availability. Specifically, keeping the open slots a patient sees perfectly in sync with the doctor's actual, constantly-changing calendar, in real time, with no double-bookings and no phantom slots. It is the least glamorous feature on the spec and the one that quietly eats the engineering budget, because it is a real-time, two-way, multi-source problem with zero tolerance for error.
The one-clock rule
The principle I build every availability engine around is what I call the one-clock rule: there must be exactly one authoritative source of truth for whether a slot is open, and everything else, the patient app, the provider dashboard, the doctor's own calendar, is either reading from it or reconciling into it. The moment you have two systems that each believe they own the truth about a slot, you have double-bookings and phantom slots waiting to happen. Availability sync, at its heart, is the discipline of keeping one clock accurate while many hands try to move it.
Where a doctor's real availability actually lives
The reason this is hard is that a provider's true schedule is scattered. Part of it is in their practice-management or EHR system. Part is in a personal calendar. Part is created by walk-ins and phone bookings your app never sees directly. If your app maintains its own view of availability in isolation, it will drift out of sync with reality within hours, and drift means either a patient books a slot the doctor already gave to a walk-in, or the app hides slots that are genuinely free. Both cost you. So the engine's job is continuous reconciliation: pull changes in from the sources that matter, push your bookings back out, and keep the single authoritative record correct through all of it.
Double-booking prevention, the part that fails silently
Double-booking is the classic failure, and it is sneaky because naive code passes every manual test and then breaks under real concurrent load. Two patients open the same 3pm slot. Both see it as open. Both tap book. If your system checks "is it open?" and then "mark it booked" as two separate steps, there is a window where both checks pass and both bookings succeed. The fix is to make claiming a slot atomic: the instant a patient begins to book, the slot is locked at the database level so only one booking can possibly win, and the lock releases quickly if they abandon. This is a solved problem when engineered deliberately and a recurring disaster when left to chance, which is exactly why it belongs to human engineering, not to a rushed or AI-generated first draft that was only ever tested by one person clicking slowly.
Time zones, the quiet trust-killer
Time zones sound trivial until a telehealth patient in New York books a doctor in London and the appointment shows up an hour off for one of them. The rule is boring and reliable: store every time in UTC internally, convert to local time only for display, using the clinic's time zone and the patient's device. Founders under-scope this because it demos fine when everyone is in one city, then it breaks the moment you cross a region, which for any telehealth ambition is immediately. Build it correctly in the first version and you never think about it again. The distinction between video and in-person visits, and how time zones interact with each, is something we unpack in how to build a doctor appointment app like Zocdoc.
Cancellations, no-shows and turning losses into fills
A strong availability engine does more than prevent errors, it recovers revenue. When a patient cancels, the freed slot should immediately become available and, ideally, be offered to a waitlisted patient automatically, turning a cancellation into a fill. No-shows should be tracked so providers can see patterns and decide on policies like reminders or deposits. The key is that every slot always has an accurate state, open, held, booked, cancelled, no-show, and that state drives the rest of the system without anyone having to intervene manually. This is where availability stops being a cost center and starts protecting the provider's revenue, which is a big part of why doctors stay on your platform.
It is worth being concrete about how much this matters to the supply side of your marketplace. A no-show is pure lost revenue for a doctor, a paid, staffed slot that produced nothing. A cancellation that goes unfilled is nearly as bad. An availability engine that automatically back-fills freed slots from a waitlist, sends the reminders that reduce no-shows in the first place, and gives the provider a clear view of their patterns is doing something no patient ever sees but every doctor feels in their monthly numbers. That is the quiet reason a well-built availability engine wins provider loyalty: it does not just avoid embarrassing double-bookings, it measurably protects the income of the people you most need to keep on the platform. Cheap builds skip this because it is invisible in a demo, and then wonder why providers drift away after launch.
What everyone gets wrong: syncing everything before proving the loop
The most common overspend I see is a founder insisting on deep integration with every EHR and practice-management system on day one. It is the right instinct for the long run, EHR integration is ultimately what makes your app painless for doctors, but doing it all up front is how you burn months and budget before you have proven anyone will book. The smarter path is phased: start with a real-time availability engine where providers manage their slots directly in your app, with proper locking, double-booking prevention and time-zone handling, and validate the whole booking loop with real users. Then integrate the specific practice-management platforms your actual providers use, once you know which ones those are. Building the integration layer before you know who your providers are is optimizing a problem you do not have yet, at the expense of the one you do. This staging is part of why we scope the engine first in the common problems building a platform like Zocdoc.
Tell us what you have in mind. We turn AI prototypes and fresh ideas into shipped, scalable products, from India, for the US and UK.
How I would build it, in order
- One source of truth first. One authoritative record of slot state, everything reads from or reconciles into it. No exceptions, no second clock.
- Atomic slot locking. Make claiming a slot a single indivisible operation so double-booking is impossible even under heavy concurrent load, then test it under exactly that load.
- UTC everywhere, local on display. Store in UTC, convert for the clinic and the patient, so time zones never produce a wrong-hour appointment.
- State-driven cancellations and waitlist fills. Every slot has an accurate state that automatically drives reminders, waitlist offers and no-show tracking.
- Phased external integration. Manual provider calendar in the MVP, automated EHR and practice-management sync once you know which systems your providers actually run.
- Mock-booking tests before launch. Run concurrent internal bookings to prove the locks hold and the reconciliation is correct, because this is precisely the flow that fails silently otherwise.
That last step is a hard-won habit for us: the near-miss that taught it was an integration that looked connected but was never exercised end to end, so now we run internal mock bookings to confirm the whole flow syncs and every field lands correctly before anyone real touches it. This is exactly how our app development and custom software teams build the availability engine, first, deliberately, and load-tested, from India for US, UK and EU founders, with the code in your name. It is the least visible part of a booking platform and the one that most decides whether it works.
Frequently asked questions
How does real-time doctor availability sync work?
A booking platform keeps its own record of each provider's open slots and continuously reconciles it with the provider's real calendar or practice-management system. When a patient books, the slot is locked instantly across the platform, and any change made in the doctor's own calendar or EHR flows back so the app never shows a time that is actually taken. Getting that two-way reconciliation right, fast and without conflicts, is the core engineering challenge.
Why is availability the hardest part of a booking app?
Because it is a real-time, two-way, multi-source problem with zero tolerance for error. A doctor's true availability lives in several places at once, their practice-management system, their personal calendar, walk-ins, phone bookings, and your app must reflect the truth of all of them within seconds. Show a slot that is gone and you break patient trust; hide a slot that is open and you lose a booking. Both failures are expensive.
What is double-booking and how do you prevent it?
Double-booking is two patients landing the same slot because the system let both start booking before either finished. You prevent it by locking the slot the instant a patient begins to book it, using atomic operations in the database so only one booking can ever win, and releasing the lock quickly if they abandon. It sounds simple and is a classic place where naive implementations quietly fail under real concurrent load.
Do I need to integrate with EHR or practice-management systems?
Eventually, usually yes, if you want doctors to adopt you. Providers will not manually maintain a separate calendar in your app on top of the system they already run their practice on. Integrating with their existing EHR or practice-management software so availability syncs automatically is what makes your app painless for them. It is also one of the more complex integrations you will build, so it is often phased in after a manual-calendar MVP.
How do you handle time zones?
Store every appointment time in UTC internally and convert to local time only for display, based on the provider's clinic time zone and the patient's device. This matters more than founders expect for telehealth, where a patient in one zone books a doctor in another. Time-zone bugs produce appointments that appear an hour off, which erodes trust instantly, so it is worth getting right from the first version.
What happens with no-shows and last-minute cancellations?
A good availability engine treats a cancellation as a freed slot and can immediately offer it to a waitlisted patient, turning a loss into a fill. No-shows should be tracked so providers can see patterns and, if they choose, apply policies like deposits or reminders. The key is that the slot's state, open, held, booked, cancelled, no-show, is always accurate and drives the rest of the system automatically.
Can I build availability sync with a simple calendar at first?
Yes, and often you should. A sensible MVP lets providers manage availability directly in your app with real-time slot locking and double-booking prevention, before you take on deep EHR integration. That proves the core booking loop works with real users. You then add automated sync with external systems once you know which practice-management platforms your providers actually use. Building all integrations up front is a common way to overspend.
Can appico build a real-time availability engine for my platform?
Yes. The availability engine is the part of a booking platform we scope first, because it is where these builds succeed or fail. We build real-time slot management, double-booking prevention, time-zone handling, waitlist fills and phased EHR or practice-management integration, from India for US, UK and EU founders, with the code and accounts in your name, and we test it with internal mock bookings under concurrent load before launch.
“Disciplined, committed, over-delivers. Three years in, I would re-hire any day.”
“A factory of ideas.”
“A fantastic-looking and performing website.”
Talk to the team, we reply within 24 hours, and the first consultation is free.
Start a conversation →