How to Build an App Like Mindbody: The Studio Owner's Guide

Mindbody charges $139 to $599 per month, per location. A yoga chain with five studios pays between $8,400 and $36,000 a year. A franchise with 10 locations pays over $100,000 annually. And after all that, Mindbody owns the software, the interface your members use, and the relationship data.

The math on a custom platform is straightforward. A purpose-built gym management system costs $140K-$200K to build. At $100K per year in Mindbody fees, you break even in 18-24 months. After that, you own the platform and the member data.

This guide covers what it takes to build that platform. Class scheduling, membership billing, check-in, POS, the member app, multi-location support, and the full tech stack.

Who Builds This?

The clients building Mindbody alternatives are not startups. They're established fitness businesses that have grown past the point where Mindbody's pricing makes sense.

Boutique studio chains are the most common. A yoga, Pilates, CrossFit, or martial arts operator that started with one location and now has three to ten is paying Mindbody fees that have compounded with every location added. They also want features Mindbody doesn't offer: deeper loyalty integration, custom member engagement flows, specific reporting formats.

Gym franchises have the same economics at larger scale, plus a harder constraint: brand consistency. Every location needs to look like the same brand to the member. Mindbody's white-label options are limited and expensive.

Corporate wellness operators build platforms for their specific program design. A company running an employee wellness benefit can't customize Mindbody to match their program structure. A custom platform does exactly what their HR team needs.

University recreation centers have procurement and data sovereignty requirements that commercial SaaS products don't meet. Custom is often the only viable path.

The fastest-growing segment is boutique brands building direct member relationships before a franchise expansion. They want the technical infrastructure in place before they have the leverage problem: 20 franchisees locked into a vendor they didn't choose.

Class Scheduling: The Operational Core

Class scheduling is not a calendar. It's a seat inventory management system with a queue attached.

Each class has a fixed structure: a schedule (weekly recurring or one-off), a capacity (12 spots in a spin class, 20 in a yoga room), an instructor assignment, a location, a price, and a booking window (members can book up to 7 days in advance, or up to 1 hour before).

When a class fills, new booking requests go to a waitlist. Waitlist position is first-come, first-served. When a booked member cancels, the system has 60 seconds to perform a chain of actions: remove the cancelling member's booking, move the first waitlist member to confirmed status, send them a push notification and an email, update their class pack balance if applicable, and log the whole transaction.

That chain of actions is a queue job. It cannot run synchronously in the HTTP request handler for the cancellation. If the push notification service is slow, the HTTP request would time out. You queue the job, the cancellation API returns immediately, and the queue processes the downstream effects asynchronously.

Late cancellation policies add complexity. Most studios charge a fee or deduct a class credit for cancellations within a cutoff window (typically 12-24 hours before class). Your booking engine has to check the cancellation time against the class start time, apply the correct policy, and charge the member or deduct the credit before releasing the spot.

Membership Management and Billing

Fitness studios sell three types of access: time-based memberships, credit packs, and single sessions.

A monthly unlimited membership gives the member access to any class as many times as they want during the billing period. Stripe handles the recurring charge: a subscription with a monthly billing cycle, automatic renewal, and prorated charges when a member joins mid-month.

A 10-class pack is a credit balance. The member pays upfront for 10 credits. Each class booking deducts one credit. Credits can expire (valid for 90 days from purchase) or not. Your database tracks the purchase date, expiry date, and current balance per pack.

Pause and freeze functionality is operationally necessary. A member going on a 3-week vacation shouldn't pay for a month they can't use. A freeze pauses billing (for Stripe subscriptions, this means cancelling the current subscription and creating a new one at the resume date) and extends the membership end date accordingly.

Family accounts let one billing entity cover multiple member profiles. A parent pays one monthly fee and two children can each book classes. The data model requires a relationship between account (billing) and member (booking) that aren't required to be the same person.

Annual memberships are a retention tool: members who pay annually churn at roughly half the rate of monthly members. The billing model is a single charge via Stripe payment intent, not a subscription. Refund policy for early termination gets complex. Define it before you build it.

We've built membership billing for four different studio operators. The one thing that always surprises clients is how complex the pause/freeze logic becomes. You need to handle partial months, pro-rated refunds, Stripe subscription timing edge cases, and the case where a member freezes, the freeze period expires, and they never explicitly unfreeze. Every studio has slightly different rules. Build the policy engine to be configurable, not hardcoded.

Instructor Management

Instructors need their own interface. They don't use the admin dashboard (too much access) and they don't use the member app (wrong information architecture). They need a dedicated instructor view.

An instructor's needs are specific: see my upcoming classes, see who's booked and who checked in, mark attendance, view my pay summary for the month.

Instructor pay structures vary by studio: flat rate per class, hourly rate, or commission (a percentage of class revenue above a threshold). Your reporting module needs to calculate pay correctly for each structure, per instructor, per pay period.

Availability management is the scheduling input: instructors set their available time slots. The admin builds the class schedule from available instructors. If an instructor is unavailable and they're assigned to a class, the system should flag it.

Sub requests are operationally messy but necessary. An instructor gets sick and needs a substitute. Your platform can handle this as a simple notification to other qualified instructors, or as a formal sub request workflow with approval. For most studios, notification is enough for v1.

Check-In: QR Codes and Attendance

Member check-in sounds trivial. It isn't.

The QR check-in flow works like this: the member opens the app. They navigate to their upcoming class. They tap "check in" and a QR code appears. The staff member or a studio kiosk (an iPad in the lobby) scans it. The system confirms their booking, marks attendance, deducts a class credit if applicable, and logs the check-in time.

That QR code must be unique per booking and time-limited. A code that's valid for 30 minutes before and after class start prevents fraud. The code is a signed JWT containing the booking ID, member ID, class ID, and an expiry timestamp. The scanner validates the signature and checks the expiry server-side.

Staff check-in (looking up a member by name on a tablet) is the fallback. It adds a name search API call but removes the app dependency for members without the app installed.

Attendance data feeds directly into reporting: class utilization, no-show rate, peak booking times, instructor attendance patterns. This is operational data studio managers look at weekly.

Point of Sale

Studios sell more than classes. Merchandise, supplements, water, training gear, gift cards. All of it needs to go through POS.

An iPad running your web admin app (React, optimized for touch) serves as the POS terminal. Stripe Terminal is the card reader: a Stripe-provided physical device that connects via Bluetooth to the iPad and processes chip, contactless, and swipe payments.

The POS needs a product catalog with price, SKU, and stock quantity. A cart interface for ringing up multiple items. Payment via Stripe Terminal, or charge to a member's account (no physical card needed). Receipt via email or SMS.

Gift cards are a separate data type: a unique code, a balance, and an expiry date. Gift cards can be sold as physical cards (with codes printed) or digital (delivered by email). When a member redeems one, your payment processing checks the gift card balance first, then charges the remainder to their card.

Personal training packages are a service sale: 10 sessions with a specific trainer, prepaid. The purchase creates a session credit balance tied to that trainer relationship. Each completed session deducts one credit and is logged for the trainer's pay calculation.

The Member App

The member app is the booking interface. It's also the primary touchpoint with your brand.

What it needs: a class schedule view (by date, by location, by class type), booking with instant confirmation, waitlist joining, booking history, membership and credit balance, payment history, and a profile with notification preferences.

Push notifications are operationally critical. A member needs to know immediately when they're moved from waitlist to confirmed. They need a class reminder 1-2 hours before. They need a payment failure notification so they can update their card before their membership lapses.

SendGrid handles transactional email. Twilio handles SMS for members who prefer texts. Firebase Cloud Messaging handles push notifications to the app. All three are triggered from the same notification service in your backend. The notification service decides which channel to use based on the member's preferences.

The booking flow must be fast. A member who can't book a class in under 10 seconds on a good connection will abandon the flow. No confirmation screens. Tap the class, tap "book", get a confirmation. Keep it three taps or fewer.

Multi-Location Architecture

Multi-location is where the data model gets interesting.

Each location has its own schedule, class types, instructors, capacity settings, and opening hours. A member can see all locations in the app and filter by their preferred one. Cross-location booking works: a member with a membership at Studio A can book a class at Studio B without any special action.

At the data model level, every class is associated with a location_id. Every booking is associated with both a member_id and a location_id. Revenue is attributed to the location where the class was held, not where the member's home location is.

This location-level revenue attribution is the key requirement for franchise accounting. Each franchisee sees only their location's revenue in the reporting dashboard. The franchisor sees all locations with comparison views. User roles and data access permissions are location-scoped.

Scheduling rules can be global (all locations offer the same class types) or per-location (Studio A offers hot yoga, Studio B doesn't). Your admin architecture needs to handle both. A global class type catalog with per-location schedule instances is the right data model.

Staff management is also location-scoped. An instructor at Studio A can't be scheduled at Studio B unless they're explicitly added to that location's staff roster. Their pay is tracked per location if they teach at multiple sites.

The Tech Stack

React (not React Native) for the admin dashboard. Studio managers and front desk staff use this on a desktop or iPad, not a phone. A responsive web app works better than a native iPad app here: easier to update, no App Store approval delays.

React Native for the member app and the instructor app. Both are phone-first. Cross-platform is the right choice: most fitness studios serve a mix of iOS and Android members.

Node.js for the backend API. Standard choice, fast development, ample developer pool.

PostgreSQL for all primary data storage. Classes, bookings, memberships, payments, attendance, instructor schedules. Relational data with complex queries. PostgreSQL handles it well.

Stripe for payments: recurring subscriptions for monthly memberships, payment intents for class pack purchases, Stripe Terminal for POS. One provider, one dashboard, one reconciliation process.

SendGrid for transactional email. Twilio for SMS. Firebase for push notifications.

The full stack: React (admin), React Native (member + instructor apps), Node.js, PostgreSQL, Stripe, SendGrid, Twilio, Firebase. No surprising choices. Every piece of this stack has deep documentation and a large developer market.

Timeline and Cost

A full build with admin dashboard, member app, instructor app, Stripe billing, Stripe Terminal POS, QR check-in, multi-location support, and reporting takes 14-18 weeks with a team of 5-7.

The cost range is $140K-$200K.

What pushes it to $200K: multi-location from day one with per-location reporting, full franchise accounting, Stripe Terminal POS with gift cards and personal training package sales, advanced instructor pay calculation (multiple pay structures, sub tracking), and a native iOS app separate from the Android build. What holds it near $140K: single location first, Stripe Terminal POS as a v2 item, simpler instructor management.

A single-location MVP with class scheduling, membership billing, check-in, and a basic member web app (not native) runs $80K-$110K in 10-12 weeks. Right for validating the concept at one location before expanding.

Ongoing costs at launch: Stripe processing fees (2.7% + 5 cents for Terminal transactions, 2.9% + 30 cents for online), SendGrid ($50-$200/month at scale), Twilio SMS ($0.0079 per message), Firebase (free under most launch-scale volumes), PostgreSQL hosting on AWS RDS or GCP Cloud SQL ($200-$800/month depending on size).

[INTERNAL-LINK: See how we scope fitness platform builds → our MVP development process]

Frequently Asked Questions

How much does it cost to build a gym management app like Mindbody?

A full platform with admin dashboard, member app, instructor app, Stripe integration, POS, and multi-location support costs $140K-$200K. A single-location MVP with scheduling, memberships, and basic check-in runs $80K-$110K. Timeline is 14-18 weeks for a full build with a team of 5-7.

What features does a fitness studio management platform need?

Class scheduling with waitlist auto-fill, membership management (monthly unlimited, class packs, drop-in), Stripe subscription billing with pause/freeze support, instructor management, QR code check-in, iPad POS with Stripe Terminal, member app with push notifications, and reporting on class utilization, revenue by membership type, and attendance trends.

How does class scheduling with waitlist work?

Classes have a capacity limit. When a class fills, new bookings go to a waitlist. When a booked member cancels, the system automatically moves the first waitlist member to confirmed, sends a push notification and email, and deducts a class credit if applicable. The cancellation triggers an async queue job, not a synchronous API call.

What payment stack should I use for a fitness studio app?

Stripe handles both recurring billing (monthly memberships) and in-person POS (Stripe Terminal card reader on an iPad). This single provider covers subscription management, class pack payment intents, and physical transactions with a unified reporting dashboard and single reconciliation process.

How do you handle multi-location in a gym management platform?

Each location has its own schedule, staff roster, and classes. Members book at any location from a single app account. Revenue is attributed to the class location in PostgreSQL. User roles are location-scoped so franchisees see only their data. The franchisor dashboard shows all locations with comparison reporting.

The Mindbody fee isn't just a cost. It's a dependency. Every year you pay it, you're more embedded in their data model, their member records, their API. Moving off gets harder, not easier.

Building a custom platform is a capital decision, not a technology decision. At 5 locations paying $36,000 a year, the break-even is under 6 years. At 10 locations paying $100K, it's under 2 years. After that, you own the software, the member data, and the relationship.

[INTERNAL-LINK: Our mobile and web development team → mobile app development services] has built class scheduling systems, Stripe billing integrations, and multi-location architectures for fitness and wellness operators. Fixed scope, fixed timeline, 14-18 weeks.