Calendar sync is the product

Everything depends on knowing someone's real availability, right now, across calendars they don't manage in your app.

Two-way sync. Read existing events to block availability; write bookings back so other tools see them. Read-only sync produces double-bookings and destroys trust immediately.

Webhooks, not polling. Google Calendar and Microsoft Graph both push change notifications. Polling every few minutes is both expensive and too slow: a meeting booked elsewhere sixty seconds ago must already block your slot.

Token refresh and revocation. OAuth tokens expire and users disconnect accounts. Handle re-authentication gracefully; silently failing sync is worse than no sync because the user still trusts it.

Multiple calendars per user. Work and personal both block availability, but only one should receive bookings.

Timezones are where these products break

Store instants in UTC, always
Store the host's timezone as a property, "9am" means their 9am
Recurring availability stores local time plus zone, never a fixed UTC offset, or daylight-saving shifts every future slot by an hour
Display both parties' timezones on the booking page and in the confirmation

Timezone bugs here don't produce error messages. They produce missed meetings.

Booking rules people actually need

Buffer before and after, minimum notice, maximum bookings per day, date-range limits, and the increment slots start on. These are the difference between a demo and something a person will rely on.

Team scheduling changes the model

Round-robin distribution with fairness tracking, collective events requiring several people free simultaneously, and routing rules that pick the right host from form answers. This is also where the money is: team scheduling is the paid tier in essentially every product in this category.

Concurrency

Two people booking the last slot at the same moment is normal. Enforce uniqueness at the database level with a constraint on host and time range. Application-level checking will let doubles through under load, and in this product a double-booking is the one unforgivable failure.

Related builds

How to build a booking app, availability modelling in depth
How to build a SaaS MVP, tenancy and billing for the paid tier
How to build an app like Zocdoc: scheduling with supply discovery

FAQ

How does calendar sync work in a scheduling app?

Two-way: read existing events to block availability and write bookings back so other tools see them. Use webhook change notifications from Google Calendar and Microsoft Graph rather than polling, since a meeting booked elsewhere a minute ago must already block the slot. Read-only sync causes double-bookings and destroys trust.

What's the most common bug in scheduling apps?

Storing recurring availability as a fixed UTC offset instead of local time plus timezone. When daylight saving changes, every future slot shifts by an hour. These bugs produce no error message: they produce missed meetings, which is why timezone handling deserves attention up front.

What features justify a paid tier in a scheduling product?

Team scheduling, almost universally: round-robin distribution with fairness tracking, collective events needing several people free at once, and routing rules that select a host from form answers. Individual scheduling is the free acquisition tier in essentially every product in this category.