STARTING PROMPT 1 — Build Your Own Booking Calendar (a Calendly replacement)
Hand this to Claude, or another capable AI coding assistant. Fill in the [bracketed parts] first.

---

Build me a free, self-hosted booking calendar to replace Calendly.

What it does. Visitors come to a web page, see a list of open dates and times, pick one, fill
out a short form, and submit. On submit, the slot is instantly claimed, the booker gets a
branded confirmation email and a calendar invite, and I get an admin notification.

My setup. I have a Google account at [scheduling@yourdomain.com], and its calendar is the one
bookings should read from and write to. I have web hosting at [host name] where I can upload
static files, or I need you to recommend a free option. I want to host it at
[book.yourdomain.com].

The booking flows I need. [Describe each one — for example, one public flow for prospective
clients and one private flow, shared by link only, for existing clients. Say how long each
meeting runs.]

Architecture I want (keep it free, no subscriptions). The frontend is static HTML, CSS, and
JS that I upload to my host. The backend is a Google Apps Script Web App that runs as my
calendar's Google account and does the calendar read and write. Availability is controlled by
pre-creating recurring calendar events titled exactly [Meeting Name] - OPEN. The script lists
those as open slots, and on booking it rewrites the title to claim the slot and adds the
booker as a guest.

Availability, the other way. Instead of one recurring event per slot, offer me the option of
one recurring daily block titled [Meeting Name] - OPEN that the script slices into start
times. Use a fixed step, and pick a step that goes evenly into the meeting length plus the
buffer so bookings pack without odd gaps. In that design a booking becomes its own event and
the block is left alone; the busy check hides the taken time. Explain the trade-off and let
me choose.

Page shape. [Pick one: a flat list of upcoming times, or a month calendar where I click a
day, see its times, then fill in the form. If you are not sure, ask me.]

Booking rules I want. [Pick what applies — a minimum notice window such as 24 hours, a buffer
around every booking such as 15 minutes, a cap on bookings per day, and how far ahead people
can book. Put each one in a named constant at the top of the script so I can change it
later.]

Details the script must get right.
- Enable the Calendar Advanced Service with the identifier exactly `Calendar`, and set the
  project time zone in Project Settings. Every date in every email comes from that setting.
- Take a script lock on every claim, so two visitors cannot take the same slot.
- Enforce every booking rule twice: once when listing slots and again at the moment of
  booking. A tab left open for an hour can otherwise book past the daily cap.
- Free/busy must fail closed. If any blocking calendar cannot be read, show no times at all
  rather than risk a double booking.
- List events with singleEvents: true and loop on nextPageToken. Without both, recurring
  series never expand and a busy calendar gets cut off.
- Only timed events with a title block time. All-day and untitled events do not, unless I
  say otherwise. Include the script's own calendar in the free/busy list, or blocking time
  on that account does nothing.
- Claim a recurring instance in two steps: first break the single date out as its own
  exception, then add the guest in a second patch. One combined patch puts the guest on
  every occurrence.
- Pass conferenceDataVersion: 1 whenever you create or remove a Meet link.
- On claim, append to the event description. Never overwrite it; I put join links there.

Testing. Add a LIVE constant, false by default, that suppresses all guest emails until I flip
it to true for go-live. Add a testSetup() function I can run from the editor that checks
calendar access, counts my OPEN blocks, and lists the next few bookable start times.

Build me the HTML pages, the shared CSS and JS, the complete Apps Script .gs file, and a
DEPLOY.md with setup instructions. Show me how to deploy the Apps Script Web App and wire its
/exec URL into the frontend. Use my colors and fonts — [paste your brand specs, or write "ask
me"]. Ask me any clarifying questions before you start.

---

Why this prompt works: it specifies the architecture, not just the goal. Naming the
static-frontend-plus-Apps-Script-plus-calendar pattern is what keeps the build free and
durable. Leave that out and the assistant reaches for a paid service or a server you have to
maintain. The "details the script must get right" list is the second half: each line is a
bug that a first build gets wrong unless you name it.
