Appointment Booking Planner

The problem

"Build me a booking app" is a risky prompt to give an AI coding agent. The agent picks a subtype for you, invents a data model, adds features it thinks belong, hard-codes durations and cancellation windows, reduces the booking lifecycle to one true/false field, and ships something that double-books clients when two requests arrive together. Then you spend three days untangling it.

Appointment booking is a wide field. A salon calendar, a clinic scheduler, a field-service dispatch board, a fitness class roster and a marketplace with many providers are all "booking apps", but they share almost nothing in their data models, compliance needs or screens. If the subtype is wrong at the start, every later step is built on the wrong architecture. Add the usual failures (double-booking, lost revenue from no-shows, confusion about SMS features, fear of migration, surprise marketplace fees) and a generic prompt gives a poor result.

What it is built from

The planner is based on research across more than 100 sources: live SaaS products for salons, clinics, fitness, consultants, field service and marketplaces; open-source self-hosted schedulers; CodeCanyon scripts and WordPress plugins; UI kits and admin templates; and accounts of real problems from people who run these businesses. The evidence references inside the planner come straight from that research: INV-A01 through INV-A26, TECH-01 through TECH-24, UI-P01 through UI-P17, and 14 documented pain references.

A coding agent cannot say that an availability design was checked against live SaaS products including Square, Fresha, GlossGenius, Vagaro, Cliniko, Jane App, Calendly, Setmore, Jobber, Housecall Pro, Mindbody, Glofox and WellnessLiving, plus the open-source and plugin products, unless it repeats the research. The planner knows which features every booking app needs, which belong to one subtype only, which are advanced branches that should stay out of a Basic build, and which feature groups to scan for before the spec is written.

What you get

A pack of four files. Your coding agent reads them, runs a structured discovery interview and produces one build spec it can work from:

• START-HERE.md: the one file you point your agent at. You give one command, then answer the decision blocks.
• skill.md: the planner logic. It has operating rules, six Basic discovery blocks, Moderate and Advanced modes, three scope presets, rules for the UI and for booking integrity, a forbidden-family scan, an output format for the spec with 20 sections, a nine-step Basic build order and a 30-point acceptance test checklist.
• evidence-summary.md: short evidence references the planner cites while it runs, covering inventory, UI, UX observation, pain, technical, role, workflow and UI structure.
• example-output.md: a worked example showing a buyer's answers and the full spec generated from them. It is there for you to read, and the planner uses it as context only if you ask.

The generated spec covers: project brief and locked decisions, a list of what is out of scope, a feature table with its evidence, roles and permissions, data model, screen map, UI requirements, workflows, technical requirements, setup and seed data, security and privacy notes, reports, implementation phases with build steps, acceptance tests, handover and readiness checks, risks, a plan for later changes, and the result of the forbidden-family scan.

Every build step lists its tables, screens, server actions, seed data and acceptance check, and ends with a firm "do not continue until" condition.

What it covers

The planner handles three delivery depths.

Basic is for a business with one location that works by appointment, 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 a handover audit.

Moderate adds waitlist, intake forms and waivers, packages and session credits, more detailed role permissions, two-way messaging, migration/import and deeper reporting.

Advanced opens clinic records and compliance, fitness classes with roster and membership credits, field-service dispatch and service areas, marketplace profile and commission reconciliation, multi-location operations, and checks for self-hosted/plugin deployment.

These branches are opt-in only and stay out of Basic unless you choose them: 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 writes booking-integrity rules into every generated spec:

• Generated slot cards, so the customer never types a bare date.
• Availability is validated when slots are shown and again on submit.
• Conflict checks compare whole time intervals for overlap. Comparing start times alone misses conflicts.
• The spec names the mechanism that keeps two simultaneous bookings from both succeeding.
• Reports read from the real booking records. They never use seed constants or separate counters.

Tested in a build-off

This planner has been tested more than any other in the catalog. Four coding models built seven working booking apps from it: Claude Opus 4.8 in four planner runs, GLM 5.2, Composer 2.5 and Kimi 2.7. Each produced a different kind of booking business (salon, clinic, fitness studio, care desk), which shows the planner adapts to the subtype. All seven run as live demos you can log into from this page, and the full scored ranking is published as a PlanSmith benchmark.

Shears & Co., a full salon/spa back office built from this planner, ranked Best Overall in the build-off. You can log into it from the demos below.