Acuity Scheduling

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 appointment booking that replaces Acuity: services, staff, deposits, and reminders that actually arrive.

The verdict is ALMOST for one reason, so start there: **reminders are the product.** A salon that loses one no-show a week has paid for the subscription. That means SMS, and SMS means a provider, a per-message cost, and in most countries a registered sender identity with an application process. Sort that out before writing a line of code — if you cannot send a text message reliably, the rest of this is a booking form.

STACK
- Node 20+ with Fastify, server-rendered HTML
- SQLite through better-sqlite3, WAL mode
- One payment provider, hosted checkout
- An SMS provider, and email as the free fallback
- Caddy in front

THE DATA MODEL
- services: id, name, duration_minutes, padding_before, padding_after, price_cents, deposit_cents, is_active, staff_ids_json, intake_form_id, cancellation_hours, max_per_day
- staff: id, name, email, timezone, is_active; staff_schedules and date_overrides, per person
- resources: id, name, capacity — a room or a chair, because two staff cannot use one room
- appointments: id, service_id, staff_id, resource_id, starts_at_utc, ends_at_utc, client_id, status, price_cents, paid_cents, deposit_ref, answers_json, cancel_token, reschedule_token, created_at, cancelled_at, cancel_reason
- clients: id, name, email, phone, notes, no_show_count, created_at
- packages: id, client_id, service_id, sessions_total, sessions_used, expires_at, purchase_ref
- reminders: id, appointment_id, kind, channel, scheduled_for, sent_at, error — one row per intended message, so nobody is reminded twice and a failure is visible
- Every instant UTC; availability as local times with a named zone

AVAILABILITY
- One pure function: staff schedules minus existing appointments minus padding minus overrides, intersected with resource capacity and the service's own rules. No database access inside it, heavily tested
- Daylight saving handled by storing instants and recomputing from named zones, with both transitions in the test suite
- A hold while the client fills the form, and the final insert re-checks inside the transaction — the hold is a courtesy, the transaction is the guarantee

MONEY
- Deposit or full payment at booking through hosted checkout; no card data here
- A cancellation window, after which the deposit is kept, stated plainly before booking
- Packages counted down as appointments are used, with an expiry
- The booking is confirmed only from the verified webhook, never from the browser returning

REMINDERS, DONE PROPERLY
- Scheduled at fixed offsets — a day before, an hour before — as rows, written when the appointment is created and rewritten if it moves
- SMS and email, with SMS the default for the day-before because that is the one that works
- A confirmation link in the message, so a client can confirm or cancel with one tap and you learn about the cancellation instead of the empty chair
- Never more than two reminders, never after the appointment
- Every send recorded with its provider reference, so a client who says they were not told can be answered

THE BOOKING PAGE
- Service, staff, day, slot, details, pay. No account, ever
- Fast on a phone, because that is where it is used
- Cancel and reschedule from long random tokens in the confirmation

OPERATIONS
- .env: DATABASE_PATH, BASE_URL, SESSION_SECRET, SMTP_URL, SMS_PROVIDER_KEY, PROVIDER_KEY, PROVIDER_WEBHOOK_SECRET
- Migrations on boot, each once; nightly backup off the machine, restore script
- Health endpoint that generates tomorrow's slots and checks both message channels

WHAT MATTERS MOST
The reminder pipeline and the availability function. Get messages actually arriving and confirm two browsers cannot take one slot. Everything else is forms.