Mythex 逐步示範：用 AI 應用程式建構工具建立 CrossFit 課堂預約系統，加入名額上限、候補名單及逾時取消規則

A 6am class with a 14-person cap looks simple until you write down what actually happens around it. Somebody books at 9pm, cancels at 5:40am, and the spot sits empty while three people on the waitlist are still asleep. A drop-in visitor from out of town shows up without having signed the waiver. Two members tap "Book" on the last spot within the same second, and the coach ends up with 15 people and 14 rowers.

Most boxes in the US and Canada solve this with gym-management software, a group chat, or both. This post walks through the other route: building a small booking system of your own, with the rules your box actually runs on. I'll use Mythex, an AI app builder, for the build, and show the exact prompts. But the parts that make a booking system hard (the data model, the last spot, the waitlist, the clock) apply whatever you build it with, so they're worth reading even if you never open the tool.

Step 0: Write the rules down before you build anything

Most booking bugs start as a rule nobody wrote down. Answer these five questions first. They become your prompts.

1. What can people book? WOD classes, open gym, on-ramp sessions for newcomers, personal training with a specific coach. Each has a different duration and capacity.
2. Who can book what? Unlimited members book any class. Class-pack holders spend a credit per class. Drop-ins pay per visit and must sign a waiver first. On-ramp graduates unlock regular classes; people still on ramp don't.
3. When does booking open and close? For example: opens 7 days ahead, closes when class starts.
4. What's the cancellation rule? For example: free cancellation up to 2 hours before class; later than that counts as a late cancel; no-shows and late cancels get tracked, and a class-pack credit is spent either way.
5. What happens when a spot opens? Either the first person on the waitlist gets it automatically and an email, or they get a notice and a short window to claim it. Automatic is simpler. A claim window is kinder to the person who'd otherwise get booked into a 6am class while asleep.

Pick one answer for each. You can change it later, but you can't build "it depends."

Step 1: Describe the data, not the screens

The first prompt matters most, because it decides the database. Describe the things in your box and how they relate, then the screens. Here's what I'd type:

Build a class booking system for a CrossFit-style gym in Denver (America/Denver time zone).

Data:
- Class types: name (WOD, Open Gym, On-Ramp, Personal Training), duration in minutes, default capacity, and whether on-ramp completion is required to book.
- Class sessions: class type, coach, start time, capacity (defaults from the class type, editable per session), status (scheduled, cancelled).
- Members: name, email, phone, membership type (unlimited, class pack, drop-in), class credits remaining (for class packs), on-ramp completed (yes/no), waiver accepted at (timestamp) and waiver version.
- Bookings: member, session, status (booked, waitlisted, cancelled, late-cancelled, attended, no-show), created at, cancelled at, waitlist position.

Rules:
- Booking opens 7 days before a session and closes at its start time.
- A session never has more "booked" bookings than its capacity. Extra requests go on the waitlist in order.
- A member can't book two sessions that overlap.

Screens:
- Members: a weekly schedule on the phone, tap a class to book or join the waitlist, and "My bookings" with cancel buttons.
- Coaches: today's sessions with the roster, and buttons to mark attended or no-show.
- Admin: create recurring sessions (e.g. WOD Mon–Fri at 6:00, 12:00, 17:30), manage members and class types.

Members sign in with email. Coaches and admins have their own roles and see the coach and admin screens; members never do.

Notice three things. The time zone is named up front, because "6am" means nothing to a server running in UTC. Capacity lives on the session, not only the class type, so a coach can shrink one class when half the rowers are being repaired. And booking status is a single field with named states, which makes "how many people are actually booked" one clear query instead of three overlapping flags.

Mythex writes the app, creates a Postgres database for those tables, and opens a live preview. Before anything else, open the admin screen, create a week of sessions, and look at the data the app stored. If a column is missing or a status is named differently from what you'd say out loud, fix it now. Renaming things after you have real bookings is much more painful.

Step 2: Protect the last spot

This is the bug that breaks trust fastest. Two members load the schedule, both see "1 spot left," both tap Book. If the app checks the count and then inserts the booking in two separate steps, both checks pass and both bookings go in.

The fix is to make "count and insert" happen as one atomic step in the database: lock the session row (or use a conditional insert) inside a transaction, so the second request waits, sees the class is full and lands on the waitlist. You don't need to write that yourself, but you do need to ask for it by name, because a generated first version may not do it:

Make booking a session safe when two members book the last spot at the same moment. Do the capacity check and the insert inside one database transaction that locks the session row, so the second request goes to the waitlist instead. Then add a small test that fires 20 booking requests at a session with capacity 14 at the same time and checks that exactly 14 end up "booked" and 6 "waitlisted".

Asking for the test is the important half. "It looks fine when I click it" proves nothing about concurrency. A test that fires requests in parallel does.

Step 3: Cancellations, the waitlist and the late-cancel rule

Now the rules from Step 0, as one prompt:

Cancellation and waitlist rules:
- A member can cancel up to 2 hours before the session starts. That's a normal cancel: status "cancelled", and a class-pack credit is refunded.
- Cancelling later than 2 hours before start sets status "late-cancelled" and does not refund the credit.
- When a booked spot is freed, promote the first waitlisted member to "booked" in the same transaction, spend their class credit if they're on a class pack, and email them that they're in, including the class time and how to cancel.
- Don't promote anyone in the last 30 minutes before start; leave the spot open for walk-ins instead.
- After a session ends, any booking still "booked" and not marked attended by the coach within 3 hours becomes "no-show".
- On the admin screen, show each member's late cancels and no-shows over the last 30 days.

Two details to look for in the preview. First, promotion has to happen in the same transaction as the cancel, or the spot can be grabbed by someone else in between. Second, the 30-minute cutoff: without it, someone on the waitlist can be booked into a class that starts before they've read the email, and then get marked as a no-show for a class they didn't know they were in.

For the emails, Mythex needs an email service connected to the app. Ask it to set one up and keep the API key in the project's secrets rather than in the code.

Step 4: Drop-ins and waivers

Drop-in visitors, often people traveling through town, are the members you know least about.

Add a public drop-in page that doesn't need an account: pick a session, enter name, email, phone and emergency contact, read the waiver and check "I agree", then book. Store the waiver version and the time it was accepted on the member record. Coaches see a waiver badge next to each name on the roster, and a warning on any booked member without an accepted waiver.

Keep the waiver text in one place and version it, so you can show which wording a person agreed to. The app can record that someone agreed; it can't tell you whether your waiver holds up where you are. Liability rules differ by state and province, so have a local lawyer write or review the wording.

Most members will book from a phone, often while still in bed, so check every screen at phone width in the preview before you check it on a laptop.

Step 5: Test the clock

Time-zone bugs are quiet until the morning they're not. Daylight saving time ends in most of the US and Canada on the first Sunday of November, and some places (most of Arizona, most of Saskatchewan) don't change at all. A recurring 6:00am class should still start at 6:00am local time the Monday after the change, not 5:00 or 7:00.

Store session start times in UTC but generate recurring sessions from the gym's local time zone, so a 6:00 class stays at 6:00 local time across daylight saving changes. Show all times to members in the gym's time zone, even if their phone is set to another one. Add a test that creates the Monday 6:00 WOD for the weeks before and after the November daylight saving change and checks both show 6:00.

The "even if their phone is set to another one" line is for the traveling member who books from an airport three time zones away and wonders why class is at 3am.

Step 6: Publish

When the tests pass, publish. You get a public URL right away; on Pro and above you can put it on your own domain, such as book.yourbox.com. Then run it alongside your current system for two weeks. Book a few classes yourself from a member account, cancel one late, join a waitlist from a second account, and see whether the emails and statuses do what Step 0 says they should.

Honest limits

• Payments are a separate step. The build above tracks memberships and class credits. Charging cards and recurring billing means connecting a payment provider such as Stripe with your own account and keys, plus some care with failed payments. Many boxes keep billing where it is and only move booking.
• You own the rules. When you change the cancellation window, someone has to ask for the change and check it. It's a sentence in a chat, but it's still your job.
• No ready-made integrations. Dedicated gym software often connects to things like workout tracking, scoring for the Open or door access. A custom app only connects to what you ask for and can reach through an API.
• Notifications are email first. Text messages need an SMS provider and the paperwork that comes with business texting in the US and Canada.

If those limits are fine, you end up with a booking system that matches your box instead of the other way around, with the database and code yours to keep.

For teams

If several coaches and an owner run the schedule, build it in a shared team workspace rather than one coach's personal account. On Mythex's Business plan (from $50/month), the workspace has Admin, Editor and Viewer roles. Coaches can view the project while one person edits it, and per-member credit limits keep one curious coach from spending the month's credits. (If you need sign-off before a change to the cancellation rule goes live, publish approvals are on Enterprise.) If you also build a staff-only tool, such as a coach payroll sheet or an incident log, you can publish it as a members-only app that only workspace members can open, with sign-in through your company's Google Workspace once the domain is verified.

The CrossFit box booking system page has a shorter starting prompt, and current plans are on the pricing page. The free plan is enough to build the first version and run the concurrency test from Step 2.

If your box has a booking rule that doesn't fit these prompts, such as a partner WOD where two people share one spot, or a members-only Saturday class, post it in the comments and I'll suggest how to phrase it.