How to Build a Booking and Scheduling App Without Code on Creatr

A booking system fails in predictable ways: double-bookings, missed time zone conversions, confirmation emails that never arrive, and no path for a customer to reschedule. This tutorial walks you through describing a complete booking and scheduling app on Creatr - no code required - so all five of those failure modes are handled before your first real booking comes in.

Before you start

Before you write your first prompt, get two things clear:

1. What is being booked? A service (haircut, consulting call, fitness class), a resource (meeting room, rental equipment), or a person's time (a doctor, a coach, a contractor)?
2. Who is doing the booking? A logged-in customer, a walk-in guest with just an email, or an internal staff member booking on behalf of a client?

These two answers shape every other decision. A guest-checkout flow for a yoga studio looks different from a client portal for a law firm. Know your answer before Step 1 - it makes every prompt tighter.

You also need a Creatr account. Sign up at getcreatr.com and start a new project.

Step 1 - Describe what is being booked and by whom

Your first message to Creatr establishes the whole domain model. Put everything in one clear paragraph: what the service is, who provides it, who books it, and any obvious business rules.

Build a booking app for a one-person personal training studio. Clients book 60-minute sessions with a single trainer. Sessions are in-person at a fixed location. Clients must create an account to book. Each client can have at most one upcoming booking at a time. The trainer can see all upcoming sessions in a dashboard and mark sessions as completed.

Creatr will generate the core data model from this description: a Session record with a start time, end time, status, and links to both the trainer and the client. If your app has multiple service types (30-minute vs. 60-minute, for example), say so now.

The studio offers two session lengths: 30 minutes and 60 minutes. Each has a different price. Clients pick the session length when they book.

Do not hold these details back for later - the earlier Creatr knows about them, the cleaner the schema it produces.

Step 2 - Set availability rules

Availability is the backbone of any booking system. You need to define when slots exist, how far in advance clients can book, and any buffer time between sessions.

The trainer is available Monday through Friday, 7 AM to 7 PM. Saturday is available 8 AM to 1 PM. Sunday is closed. Add a 15-minute buffer between sessions so back-to-back bookings are never possible. Clients can book up to 30 days in advance and no less than 2 hours before the session starts.

Creatr will generate an availability engine from this. It will block off times outside the defined window and enforce the buffer automatically.

If your availability varies by week - holidays, one-off days off - ask for the ability to block dates manually:

The trainer needs to be able to block specific dates from the dashboard. Blocked dates should remove all available slots for that day, and clients should not be able to book on those dates.

For businesses with multiple staff members, each with their own schedule:

There are three coaches. Each coach has their own availability schedule, which they can edit from their own dashboard. A client books a session with a specific coach, not just any available slot.

Step 3 - Handle time zones correctly

Time zone bugs are the most common and most damaging failure in scheduling apps. A client in Los Angeles books a 9 AM slot and the trainer in New York sees it as 9 AM - now neither one shows up at the right time.

The fix is to store all times in UTC internally and display them in each user's local time zone.

Store all session times in UTC. When a client views available slots or their upcoming bookings, display times in their browser's local time zone. When the trainer views the dashboard, display times in the trainer's home time zone, which is US/Eastern. Label all times with the time zone so it is never ambiguous.

If clients are always in the same city as the provider, you can simplify:

All clients and the trainer are in the same city. Use US/Pacific time for all time display. Still store internally in UTC.

Either way, do not skip this step. Even a single-location business will eventually have a client traveling or booking remotely.

Step 4 - Build the booking flow itself

Now describe the exact steps a client takes to book. Walk through the flow as a user would experience it.

The booking flow works like this: the client selects a session length, then sees a calendar showing the next 30 days. Days with at least one available slot are highlighted. The client picks a day, then sees available time slots for that day. After selecting a slot, they see a summary - date, time, duration, price - and confirm. Payment is collected at this step before the booking is confirmed. After payment, the booking is saved and a confirmation email is sent.

If you want a free app (no payment at booking), change the payment step:

No payment is collected at booking time. The trainer invoices clients separately. Remove any payment step from the booking flow.

To add a notes field (common for medical or service apps):

Before confirming, the client can add an optional note for the trainer - for example, a specific goal or injury to be aware of. This note appears in the trainer's dashboard view for that session.

For multi-step intake forms, describe each question explicitly. Creatr will build the form fields from your description.

Step 5 - Confirmation and reminder emails

Every booking must send a confirmation immediately. Every session should send a reminder. Both emails should include enough information that the client does not need to log in to remember what they booked.

When a booking is confirmed, send the client a confirmation email. The email should include: the session date and time in their local time zone, the session length, the trainer's name, the studio address, and a link to cancel or reschedule. Also send a reminder email 24 hours before the session with the same details.

Wire Gmail for transactional delivery so these emails do not land in spam. Mention it in the prompt:

Use Gmail to send transactional emails. The sending address is bookings@yourstudio.com.

If you also want SMS reminders, say so. Creatr can wire SMS at build time.

For the trainer, ask for a notification when a new booking is made:

Send the trainer an email notification whenever a new booking is created or cancelled. Include the client's name, the session time, and any note the client left.

See also: Send automated transactional emails for a deeper look at email delivery configuration.

Step 6 - Prevent double-bookings

Availability rules block most double-booking scenarios, but you need to be explicit about the race condition: two clients clicking "confirm" on the same slot at the same moment.

When a client submits a booking, check availability again at the moment of confirmation, not just when they first see the slot. If the slot has been taken between when they viewed it and when they confirmed, show an error and let them pick a different time. Never book two clients into the same slot.

Creatr will implement this as a transactional check at write time. It is a standard pattern - you just need to ask for it explicitly.

For group classes or shared resources where multiple bookings in the same slot are allowed:

Each yoga class has a capacity of 12. Multiple clients can book the same class up to that capacity. Once a class is full, it should be marked as full and removed from the booking flow. Clients who try to book a full class should see a message that it is full.

Step 7 - Cancellations and reschedules

A booking system without a cancellation path creates support overhead. Define the rules, then ask Creatr to build the flow.

Clients can cancel a session up to 24 hours before it starts. Inside 24 hours, cancellation is not allowed - they must contact the trainer directly. When a client cancels, the slot becomes available again immediately. Send the client a cancellation confirmation email and notify the trainer.

For reschedules:

Clients can reschedule a session up to 24 hours before it starts. Rescheduling means cancelling the current booking and booking a new slot in one step - the client should not lose their place if the new slot is available. The old slot is released immediately. Send a reschedule confirmation email.

For refund logic tied to cancellations:

If a client cancels more than 48 hours before the session, issue a full refund. If they cancel between 24 and 48 hours out, issue a 50 percent refund. Inside 24 hours, no refund. Log each refund action in the trainer's dashboard.

Be specific about the refund window numbers - Creatr will implement exactly what you describe.

Step 8 - Sync to a real calendar

A booking app that does not talk to an existing calendar creates a second calendar to maintain. Connect to Google Calendar or Outlook Calendar so bookings appear automatically where the trainer already works.

When a session is confirmed, create a Google Calendar event on the trainer's calendar. The event title should be "Session with [client name]". Include the session notes in the event description. When a session is cancelled, delete the event. When a session is rescheduled, update the event time.

For clients who use Google Calendar:

Also send the client a Google Calendar invite when their booking is confirmed. The invite should go to the email they used to register. If they decline the invite, do not change the booking status - that is handled separately.

If your trainer uses Outlook:

The trainer uses Outlook. Create calendar events in the trainer's Outlook calendar instead of Google Calendar. Use the Outlook Calendar integration.

If your workflow involves Calendly for inbound scheduling alongside your own booking app, mention both:

The trainer also uses Calendly for discovery calls. Do not replace Calendly. The booking app handles paid sessions only. There is no need to sync with Calendly.

Step 9 - Test before you go live

When Creatr returns the first build, test it against a checklist before sharing it with anyone.

Availability

• Book a session in an available slot. Confirm it appears in the trainer dashboard.
• Try to book outside availability hours. Confirm the slot is not shown.
• Book two consecutive sessions with no buffer. Confirm the second fails if it violates the buffer rule.

Time zones

• Change your browser time zone setting (or use a VPN) and view available slots. Confirm times display in the new zone, not UTC.
• Book a session and confirm the confirmation email shows the correct local time.

Double-booking

• Open two browser tabs on the same slot simultaneously and try to confirm both. Confirm only one succeeds.

Cancellation

• Cancel a session more than 24 hours out. Confirm the slot reappears on the booking calendar.
• Try to cancel inside 24 hours. Confirm the system blocks it.

Emails

• Complete a booking end-to-end with a real email address. Confirm the confirmation email arrives, the subject line is clear, and all details are correct.
• Check that the 24-hour reminder sends at the right time.

Calendar sync

• Confirm a Google Calendar or Outlook event appears after booking.
• Cancel the booking. Confirm the event is removed.

If anything is wrong, describe the problem back to Creatr in plain English and it will fix it.

Step 10 - Ship and iterate

Once testing passes, deploy from your Creatr dashboard. Share the link with a handful of real users before a wider launch.

Watch for two things in the first week: support requests about time zones (a signal your time zone display needs more labeling), and clients who book and then ghost (a signal your reminders need earlier or more frequent sending).

Both are easy to fix with a follow-up prompt:

Add a second reminder email 1 hour before the session, in addition to the 24-hour reminder.

Or:

Change all time labels to show the time zone abbreviation next to the time, for example "3:00 PM EST". Apply this to the booking flow, confirmation emails, and reminder emails.

Ship a small version, watch what breaks, and fix it. That is faster than trying to anticipate every edge case up front.

Recap

Five things break booking systems. Here is what you asked Creatr to handle for each:

Related tutorials: Send automated transactional emails - Add Stripe payments to your app