How to Build a Fitness Class Booking App, from Someone Who Built One

A class booking app looks simple on a whiteboard: list classes, tap "Book", done. Then reality arrives. Classes fill up and need waitlists. Instructors call in sick. Members buy packs of ten classes, monthly memberships and drop-ins, sometimes at more than one gym. Someone books the last spot at the same moment as someone else. A no-show blocks a spot that another member wanted.

I built Floey, a fitness class booking and gym management platform in Kuwait, end to end: the consumer app on iOS, Android and the web, Floey Business for gym owners and staff, and the multi-tenant backend that serves both. This playbook covers booking app development for fitness businesses: what a class booking app really needs, how to structure it, the rules that cause the most bugs, and what it costs to build.

Key takeaways

• There are usually three products: a member app, a staff app or dashboard for gyms, and the backend that connects them.
• Capacity, waitlists and cancellation rules are the heart of the product; get them right on the server, in transactions.
• Payments come in several shapes: drop-ins, class packs, memberships with automatic renewal and local payment methods.
• Multi-gym platforms need multi-tenancy: each gym's data, staff and branding isolated.
• An MVP for a single studio is far smaller than a marketplace for many gyms; decide which you're building first.

Two very different products

Floey is the second kind: members discover gyms and book classes, while each gym runs its business in Floey Business and gets its own branded booking site.

The features that matter

The rules that cause most bugs

Capacity under concurrency. Two members tapping "Book" for the last spot at the same moment must not both succeed. Enforce capacity in the database inside a transaction (lock the class row or use an atomic conditional update), never by checking availability in the app.

Waitlists. When a spot opens, who gets it and how fast? Automatic promotion with a notification and a short confirmation window works well; define what happens if the member doesn't respond.

Cancellations and late cancels. Decide cut-off times, refunds or credits, and penalties, per gym. Make the rule visible before booking.

Recurring classes and changes. A weekly class is a template that generates instances. When an instructor changes for one week, change only that instance and notify booked members.

Credits and entitlements. Packs, memberships and drop-ins each grant the right to book differently. Model entitlements explicitly so "can this member book this class?" has one answer in one place.

Check-in and no-shows. QR or code check-in at the door, plus no-show tracking that feeds into booking rules if the gym wants it.

Payments and renewals

Members expect to pay with the methods common in their market. In Kuwait that meant KNET, Apple Pay, Google Pay and cards. Gym classes and memberships are services used outside the app, so Apple and Google rules require payment providers rather than in-app purchase. Build billing to be idempotent and webhook-driven, with automatic monthly renewals for memberships and clear receipts.

From the field: On Floey I shipped real-time booking with instant confirmation, recurring class scheduling with capacity and instructor swaps, memberships and class packs, digital check-in and no-show tracking, coupon campaigns and staff payout reporting, with Kuwaiti payment rails (KNET, Apple Pay, Google Pay and cards), idempotent webhook-driven billing and automatic monthly membership renewals. The scheduling and entitlement rules took far more design than the screens.

Architecture

• Member app: React Native (Expo) for iOS and Android, with the same app on the web for members who book on a laptop.
• Gym app or dashboard: a separate app or web dashboard for staff, with role-based access (owner, manager, front desk, instructor).
• Backend: a multi-tenant API (Floey uses Django REST Framework on PostgreSQL, with Redis) where each gym is an isolated tenant.
• Notifications: reminders, waitlist promotions, schedule changes.
• Payments: a provider supporting your market's methods, with webhooks driving booking and membership state.

What it costs and how long it takes

Using planning ranges (hours times rate) rather than quotes:

Timelines run from about 10 to 14 weeks for a focused studio MVP to six months or more for a multi-gym platform.

Other kinds of booking apps

The same core (availability, booking rules, payments, reminders) powers many products, but the hard part shifts:

A taxi app isn't really a calendar problem at all: it's real-time matching between two sides, which is why it costs several times more than an appointment app.

Pitfalls to avoid

• Checking capacity in the app instead of the database.
• Treating memberships, packs and drop-ins as the same thing.
• Building the marketplace before one gym loves the product.
• Forgetting the front desk: check-in has to be fast at 7am with a queue.
• Hard-coding cancellation rules that each gym wants to set differently.

FAQ

How do I build a fitness class booking app?

Start with the schedule, booking, cancellation, payment and reminder flows for members, and a simple tool for staff to manage classes and check members in. Enforce capacity and booking rules on the server, integrate your market's payment methods with webhooks, and add packs, memberships and waitlists next.

How much does a fitness booking app cost?

A focused single-studio MVP typically takes 400 to 600 hours, roughly $10,000 to $60,000 depending on the developer's rate. A multi-gym platform with a business app and multi-tenant backend is a much larger project, often 1,800 to 3,000+ hours.

Should gym bookings use Apple's in-app purchase?

No. Classes and memberships at a physical gym are services consumed outside the app, and Apple's guideline 3.1.3(e) requires payment methods other than in-app purchase for those, such as Apple Pay or cards. Digital-only content, like on-demand workout videos, is different.

What's the hardest part of a booking app?

The rules rather than the screens: capacity under simultaneous bookings, waitlists, cancellation policies, recurring schedules with one-off changes, and entitlements from packs and memberships. These must be modelled carefully and enforced on the server.

Next steps

If you're building a booking app for fitness, wellness or any class-based business, I've built the full stack (member app, business app and multi-tenant backend) and can help you scope and ship yours. Get in touch, or see my work.

Sources

• App Review Guidelines (3.1.3(e)), Apple
• Row security policies, PostgreSQL docs
• Django REST framework, Django REST framework
• Expo documentation, Expo