How to build a booking system with AI

These are the parts a booking system needs before it is useful. Each one is something the plan covers.

• Services, resources and staff: Define what can be booked, for how long, with whom or what, and at what price.
• Availability rules and exceptions: Express when each resource works (weekly pattern, time off, holidays, one-off extras) in local wall-clock time.
• Double-booking prevention: Make it impossible, not merely unlikely, for two bookings to overlap on one resource.
• Booking flow with slot holds: Reserve a slot while the customer fills in details or pays, then confirm or release it.
• Time-zone handling: Show and book the correct instant for customers and staff in different zones, across DST.
• Reminders and notifications: Cut no-shows with timely confirmations and reminders.
• Cancellation, reschedule and no-show policy: Protect revenue with clear, enforced rules.
• Staff and owner dashboard: Day/week calendar, check-in, manual bookings, blocks, customer list, utilisation.

• Recurring bookings: Weekly or custom repeating appointments and classes.
• Deposits and prepayment: Collect deposits or full payment and refund per policy, with state written by webhooks.

Each table below becomes part of the Postgres database that belongs to your app.

• businesses: timezone is an IANA name validated against the time zone database; min_notice_min and max_advance_days bound the bookable window and the availability query.
• services: duration CHECK between 5 and 1440; capacity 1 = one-to-one, > 1 = class; price and deposit are snapshotted onto the booking.
• resources: kind: staff|room|equipment; one booking occupies exactly one resource in phase 1 (multi-resource bookings are phase 2).
• resource_services: defines which staff or rooms can deliver which services.
• availability_rules: local wall-clock times in the business time zone; CHECK start_local < end_local; split shifts are multiple rows; weekday 0-6.
• time_off: holidays, leave, blocks; business-wide closures are inserted for every resource by a helper.
• customers: guests can book without an account; PII fields are minimised and erasable.
• bookings: status: held|confirmed|completed|cancelled|no_show|expired; during is half-open [start,end) including buffers so back-to-back appointments touch but never overlap; price and deposit snapshotted; transitions via compare-and-set with booking_events.
• booking_events: append-only: created, held, confirmed, rescheduled, cancelled, no_show, refunded, reminder_sent.

• No check-then-insert booking logic: the exclusion constraint is the only overlap guard.
• No two-way Google/Outlook calendar sync, waitlist automation or dynamic pricing in phase 1.
• No multi-resource bookings (a booking occupies one resource) in phase 1.
• No storing card data or clinical notes.
• Calendar sync (Google / Outlook / iCal): plan for it, build it later.
• Waitlist and smart rebooking: plan for it, build it later.
• Multi-location optimisation and dynamic pricing: plan for it, build it later.

Forge64 matches your description to one of 12 reference architectures, writes the plan and data model into the project, generates the app, and runs a quality gate over the code before you see it. Each app gets its own Postgres database and sign-in with no per-user fee. Hosting on Forge Cloud and Forge Payments are rolling out.

This is a reference design for the category, not a promise that every item is generated today. Built-ins such as email, background jobs, file uploads and search are coming soon, so anything here that needs them is something you add yourself for now.

What does a booking system need first?

Services, resources and staff, availability rules and exceptions, double-booking prevention, booking flow with slot holds, time-zone handling and reminders and notifications. The plan for a booking system covers all of these before it generates code.

What should I leave out of the first version of a booking system?

No check-then-insert booking logic: the exclusion constraint is the only overlap guard. No two-way Google/Outlook calendar sync, waitlist automation or dynamic pricing in phase 1. No multi-resource bookings (a booking occupies one resource) in phase 1.

Which products define the booking system category?

Well-known examples include Calendly, Acuity Scheduling, Mindbody, OpenTable and Cal.com. Use them to decide which features your users expect, then describe your own version.

• Booking system architecture
• Example prompt for a booking system
• Booking system security checklist
• Booking system scaling checklist
• Often combined: SaaS dashboard
• Often combined: marketplace
• All app types