Appointment Booking Planner

The problem this kills

"Build me a booking app" is one of the most dangerous prompts you can hand an AI coding agent. The agent will pick a subtype, invent a data model, bolt on features it thinks belong, hard-code durations and cancellation windows, collapse the booking lifecycle to a single boolean, and ship you something that double-books clients on concurrent requests. Then you spend three days untangling it.

The appointment-booking domain is genuinely wide. A salon calendar, a clinic scheduler, a field-service dispatch board, a fitness class roster, and a marketplace multi-provider flow are all "booking apps" — but they share almost nothing in their data models, compliance posture, or UI grammar. Getting the subtype wrong at the start locks in the wrong architecture for every step that follows. Add the common failure modes — double-booking, no-show revenue leaks, SMS feature confusion, migration fear, marketplace fee surprises — and a generic agent prompt produces a generic disaster.

Why your agent can't fake this

This planner is grounded in a research pass across more than 100 sources: live SaaS products across salons, clinics, fitness, consultants, field service, and marketplaces; open-source self-hosted schedulers; CodeCanyon scripts and WordPress plugins; UI kits and admin templates; and practitioner pain sources from real operators. The evidence anchors embedded in the planner — INV-A01 through INV-A26, TECH-01 through TECH-24, UI-P01 through UI-P17, and 14 documented pain anchors — are sourced directly from that research. Your coding agent cannot reproduce "this availability design was validated across live SaaS products including Square, Fresha, GlossGenius, Vagaro, Cliniko, Jane App, Calendly, Setmore, Jobber, Housecall Pro, Mindbody, Glofox, WellnessLiving, and a full open-source and plugin layer" without redoing the scrape. That is the moat. The planner knows which features are core to every booking app, which belong to specific subtypes only, which are advanced branches that should never leak into a Basic build, and which are forbidden families to scan before writing the spec.

What you actually get

A four-file planner pack that your coding agent reads to run a structured discovery interview and produce one agent-executable build spec:

• START-HERE.md — the single file you point your agent at. One command, then answer decision blocks.
• skill.md — the planner logic: operating rules, six Basic discovery blocks, Moderate and Advanced modes, three scope presets, UI and booking-integrity contracts, a forbidden-family scan protocol, a 20-section generated spec output contract, a nine-step Basic build order, and a 30-point acceptance test checklist.
• evidence-summary.md — compact evidence anchors the planner cites at runtime: inventory, UI, UX observation, pain, technical, role, workflow, and UI IA anchors.
• example-output.md — a worked proof showing buyer answers and a full generated spec. Useful to inspect; not used as planning context unless you ask.

The generated spec covers: project brief and locked decisions, explicit non-goals, evidence-scoped feature table, roles and permissions, data model, screen map, UI requirements, workflows, technical requirements, setup and seed data, security and privacy posture, reports, implementation phases with build steps, acceptance tests, handover and readiness gates, risks, amendment roadmap, and a forbidden-family scan result.

Every build step includes tables, screens, server actions, seed data, acceptance checkpoint, and a hard "do not continue until" gate.

Coverage

The planner handles three delivery depths. Basic targets a single-location appointment-first business in 7-9 build steps: subtype selection first, then service catalog, staff and availability engine, public/mobile booking page, manual/staff booking calendar with generated slot cards, booking lifecycle, reminders and payment policy if selected, reports, and handover audit. Moderate adds waitlist, intake forms and waivers, packages and session credits, richer role permissions, two-way messaging, migration/import, and deeper reporting. Advanced unlocks clinic records and compliance posture, fitness classes with roster and membership credits, field-service dispatch and service areas, marketplace profile and commission reconciliation, multi-location operations, and self-hosted/plugin deployment gates.

Branches the planner explicitly manages as opt-in only — never leaking into Basic — include: salon/spa/barber, clinic-lite/therapy/dental, fitness/classes/personal training, repair/field service, marketplace multi-provider, consultant/professional services, full POS and retail inventory, integrated payments with card-on-file and no-show fees, clinical records and telehealth, and self-hosted or WordPress plugin installs.

The planner ships booking-integrity contracts into every generated spec: generated slot cards rather than bare date inputs, availability validation at display time and again on submit, interval-overlap conflict checks rather than exact-start equality, race-safety mechanism naming, and source-of-truth reporting from the actual booking ledger — not seed constants or parallel counters.