Calendly

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Build me a booking page that replaces Calendly — and know why the verdict is ALMOST rather than YES.

The page is straightforward. The two halves that are not: **calendar synchronisation**, where recurring events with exceptions, all-day blocks and each provider's quirks will consume most of the project, and **time zones**, where homemade schedulers reliably fail. Get both right and this is genuinely yours; get either wrong and you will double-book somebody.

STACK
- Node 20+ with Fastify, server-rendered HTML with a little vanilla JS
- SQLite through better-sqlite3, WAL mode
- Caddy in front

THE DATA MODEL
- users: id, name, slug, email, timezone
- event_types: id, user_id, slug, title, description_md, duration_minutes, buffer_before, buffer_after, min_notice_minutes, max_days_ahead, max_per_day, location_kind, location_value, requires_confirmation, is_active
- schedules and availability_rules: weekday, start_local, end_local, with a named zone
- date_overrides: id, user_id, date, is_unavailable, start_local, end_local
- bookings: id, event_type_id, uid, starts_at_utc, ends_at_utc, attendee_name, attendee_email, attendee_timezone, answers_json, status, cancel_token, reschedule_token, external_event_id, created_at
- calendar_connections: id, user_id, provider, credentials_encrypted, calendar_ids_json, write_calendar_id, sync_token, last_synced_at
- busy_blocks: id, connection_id, starts_at_utc, ends_at_utc, source_event_id, fetched_at — intervals only, never the event details. The organiser's meeting titles are none of this tool's business

TIME, WHERE THIS GOES WRONG
- Every instant in UTC. Availability rules as local times with a named zone, because 09:00 in Europe/Rome is a different instant in July and in January
- A real time zone library and the IANA database. Never an offset
- The test suite includes a spring-forward day, an autumn-back day, and a zone whose rules changed
- The attendee sees their own zone with the organiser's beside it
- All-day and multi-day concepts are dates, not midnight instants

CALENDARS, WHERE THE TIME GOES
- Two-way with the major providers, read-only ICS for anything else
- Incremental sync with the provider's sync token, plus a full reconcile on a schedule, because incremental sync drifts
- Recurring events expanded properly — recurrence rules with exceptions and moved instances are what break naive implementations, and a wrongly expanded weekly meeting means double bookings for a year
- All-day events are dates in the calendar's own zone and must not be treated as 00:00 to 00:00 UTC
- Declined and tentative events: decide whether they block, per connection, and say so
- Write the booking to a chosen calendar with the attendee invited, and update or delete it when the booking changes

SLOT GENERATION
- One pure function: rules minus busy blocks minus existing bookings with buffers, then notice, horizon and daily cap, rounded to an increment. No database access inside it, tested heavily
- A hold while the form is filled, released after a few minutes; the final insert re-checks availability inside the transaction. The hold is a courtesy, the transaction is the guarantee

BOOKING
- Pick a day, pick a slot, answer the questions, confirm. No account, ever
- Optional confirmation by the organiser, with approve and decline
- Cancel and reschedule from long random tokens in the email
- Confirmation to both sides with an ICS attachment and hand-built add-to-calendar links, reminders at configured offsets, each recorded so nobody is reminded twice

OPERATIONS
- .env: DATABASE_PATH, BASE_URL, ENCRYPTION_KEY, SESSION_SECRET, SMTP_URL, provider client ids and secrets
- Migrations on boot, each once; nightly backup off the machine, restore script
- Health endpoint that generates tomorrow's slots and reports sync age per connection

WHAT MATTERS MOST
Recurrence expansion and the booking transaction. Write the time zone tests before the interface exists, then have two browsers book the same slot at once and confirm exactly one succeeds.