SavvyCal

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 scheduling link that replaces SavvyCal: the person booking can lay their own calendar over mine and pick a time that works for both.

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

THE FEATURE THAT IS THE WHOLE PRODUCT
- A normal booking page shows a list of slots and makes the other person cross-reference it against their own week. That is work you have pushed onto them, which is why receiving a scheduling link feels slightly rude
- Here, the person booking connects or pastes their own calendar and sees both availabilities on one grid. The times that work for both are obvious, and nobody does arithmetic
- Two ways in, and both matter: connect a calendar with OAuth, or paste a read-only ICS URL. And a third for the reluctant — upload nothing, and just use the ordinary slot list
- Whatever they connect is used in the browser and for that session only. Never stored, never sent to the organiser, discarded when the page closes. Say that on the page, in one sentence, at the moment you ask — otherwise nobody connects anything

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
- ranked_windows: id, event_type_id, weekday, start_local, end_local, weight — the preferred times
- 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 and busy_blocks — only intervals, never event details
- The guest's calendar has no table. That is deliberate and it is the promise

RANKED AVAILABILITY
- Not every free hour is equally welcome. Windows carry a weight, and preferred times are shown prominently while the rest are available but quieter
- The other person still sees everything, so nothing is hidden — they are simply nudged. That is the honest version of the feature, and hiding real availability to force a preferred slot is the dishonest one
- Weights per event type, so a sales call and a deep-work review can prefer different halves of the day

TIME, WHICH IS WHERE HOMEMADE SCHEDULERS DIE
- 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 guest sees their own zone by default with the organiser's shown beside it, and the overlay grid is drawn in the guest's zone

SLOT GENERATION
- One pure function: take the rules, subtract busy blocks, subtract existing bookings with their buffers, apply notice, horizon and daily cap, round to an increment, and return slots with their weights
- No database access inside it, and tested heavily. Everything else in this product is forms

CALENDARS
- Two-way with the major providers, and 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 are what break naive implementations, and a wrongly expanded weekly meeting means double bookings for a year
- Only busy intervals stored from the read side. The organiser's meeting titles are none of this tool's business

BOOKING
- Pick, fill, confirm. No account, ever
- A hold on the slot while the form is filled, released after a few minutes; the final insert re-checks availability inside the transaction, which is the actual guarantee
- Custom questions, validated on the server
- Cancel and reschedule from long random tokens in the email, no account

NOTIFICATIONS
- Confirmation to both sides with an ICS attachment and hand-built add-to-calendar links
- Reminders at configurable offsets, each recorded so nobody is reminded twice
- A one-click cancellation link in every one

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

WHAT MATTERS MOST
The overlay and the promise about the guest's calendar. Build the two-calendar grid first and make the discard-after-session behaviour real, then have two browsers book the same slot at once and confirm exactly one wins. The overlay is the only reason to build this instead of any other scheduler, and the promise is the only reason anyone will use it.

Give me the repository, migrations, .env.example, a seed user with ranked windows, and a README with deploy steps behind Caddy and the OAuth setup for each provider.