What stops a copy of Calendly working?

Availability is deceptively hard. Two calendars, recurring events, all-day events, declined invitations and a working-hours window intersect into something you will get wrong at least six times. Time zones. Not the conversion, which is a library call, but the ambiguity: whose zone is the slot in, and what happens when daylight saving moves underneath a booking made three weeks ago. Double bookings under concurrency. Two people loading the same slot need one of them to lose, and that requires a real lock rather than an optimistic read. Calendar provider APIs, which are each idiosyncratic, rate-limited, and prone to expiring your refresh token on a Sunday.

Can AI copy

Calendly

Q: Can AI copy Calendly?

Skin deep. You will clone the interface and then meet the wall. Realistically a long weekend.

A link that lets a stranger take a slot out of your calendar without four emails first.

Skin deep

Verdict: Skin deep
Time to copy: a long weekend
Category: ▧ Productivity
Source: Proprietary

The prompt

Written to be pasted straight into an agent with no editing. It describes the whole job, including the parts that will go wrong.

Build a scheduling app. OAuth into Google Calendar and Microsoft Graph, read busy blocks from all selected calendars, and intersect them with configurable working hours, minimum notice, buffers before and after, and a per-day booking cap. Public booking page at /:user/:eventType showing slots in the visitor's detected time zone with an explicit zone selector. Booking writes the event to the host calendar and sends confirmations with reschedule and cancel links. Handle concurrency with a transactional lock so a slot cannot be double-booked. Store all times as UTC instants plus the original IANA zone, never as local strings.

Open inClaude ↗Terminal agents take it from the clipboard.

What copies cleanly

The booking page. A month grid, available slots, a form, a confirmation.
Event types with durations, buffers and a daily cap.
The emails, the reschedule link, the cancel link.

Where it stops

Availability is deceptively hard. Two calendars, recurring events, all-day events, declined invitations and a working-hours window intersect into something you will get wrong at least six times.
Time zones. Not the conversion, which is a library call, but the ambiguity: whose zone is the slot in, and what happens when daylight saving moves underneath a booking made three weeks ago.
Double bookings under concurrency. Two people loading the same slot need one of them to lose, and that requires a real lock rather than an optimistic read.
Calendar provider APIs, which are each idiosyncratic, rate-limited, and prone to expiring your refresh token on a Sunday.

What actually protects them

Not much, honestly. The category has real open-source competition and the incumbents know it.
The verb. People say send me your Calendly the way they say hoover.

Editor's note

The classic case where the interface takes a day and the correctness takes a month. Everyone who has built one has a time zone story.

Somebody already did it

Cal.comcal.comOpen source and mature. If you are copying this, start by reading how they modelled availability.

Go and look at the original

We would rather you formed your own opinion than took ours. They built the thing; we only measured it.

calendly.com ↗