Case study · Fitness & wellness
A booking platform that fills classes, not inboxes
Peach wanted one place for fitness and yoga studios to publish a timetable, sell memberships and take bookings — and an app that lets members book a class in seconds. We designed and built it for iOS, Android and web over a two-year engagement.
Engagement · Development & scaling
A two-year product engagement across three platforms.
- Industry
- Fitness, yoga & wellness
- Solution
- Class booking platform
- Engagement model
- Dedicated product team
- Engagement length
- 2 years (Jan 2021 – Jan 2023)
- Market stage
- Launch & scaling
- Client
- Peach, Sweden
- Scope
- End-to-end product engineering
- Platform
- iOS · Android · Web
Outcomes
What changed once studios were running on it
The figures a booking platform is judged on are about time saved and classes filled, not downloads.
-
70%
Increase in repeat bookings
Members book their next class in the app while the last one is still fresh, instead of waiting to message the studio. Repeat attendance is the number a studio lives on.
Reported by studios across the first year on the platform
-
90%
Less booking admin for studio owners
Confirming places by direct message was an evening's work. The app does it, and the owner stops being the booking system.
Reported by studios after the member app went live
-
45%
Growth in memberships and class packs sold
Memberships and packs are bought in two taps at the moment a member decides, rather than arranged by message and paid for later — or not at all.
Measured across memberships and packs sold through the platform
Context
The situation before the platform
Why a fitness brand needed one product rather than a spreadsheet, a social feed and a card reader.
The business
A Swedish fitness and yoga business serving independent studios and their members, where instructors publish the timetable and members book the classes they want to attend.
The starting point
Timetables lived in spreadsheets, class changes went out on social media, memberships were tracked by hand, and payments were chased one message at a time.
The trigger
It holds together until a studio adds a second instructor and a second room. At that point double bookings start, and the admin outgrows the evening it used to take.
What they wanted
One product: a member app for finding and booking classes, and a studio side for publishing the timetable and handling memberships and payments — on phones and in a browser.
Constraints
Booking rules differ per studio: cut-off times, waitlists and late-cancellation policies · payments, refunds and class-pack balances have to reconcile exactly · two app stores and a web app kept in step from one codebase · studios and gyms have poor signal, so the app cannot assume a connection.
System
What it runs at today
The platform as delivered, live across mobile and web.
-
4
Booking rule types
Cut-off times, waitlists, per-member limits and late-cancellation policies, each configurable per studio
-
3
Payment models
Recurring memberships, fixed class packs and pay-as-you-go, all in one checkout
-
2
App stores
App Store and Google Play releases, maintained through two years of platform policy changes
-
5.0
Client rating
Rated by the client in a verified review published on Clutch
The engineering problem
Four problems that shaped the build
Not vague pain points — the specific tensions in building one booking platform for studios that all run differently, each paired with what we did about it.
-
Every studio believes its booking rules are the normal ones
Cut-off times, waitlist behaviour, how many classes a membership allows per week, what happens when someone cancels an hour before — each studio had its own answers, and all of them considered their version obvious. Hard-coding any one studio's rules would have made the product unsellable to the next.
What we did
A rule engine where booking policy is configuration rather than code, so onboarding a studio with different rules is a setup task rather than a development ticket.
-
A booking has to be safe when the network is not
Members book on the way to class, on mobile data, in stairwells and basements. A request that times out must not leave a place half-reserved, and a member pressing the button twice must not take two places or be charged twice.
What we did
Booking made atomic on the server with idempotent requests, so a retry resolves to the same single booking rather than creating a second one.
-
Money and entitlements have to agree, always
A class pack with three sessions left, a membership that renews mid-week, a studio cancelling a class that members paid for — each of these changes what somebody is owed. If the entitlement and the payment record disagree, the studio finds out from an angry member.
What we did
Entitlements and payments modelled together from the start, with every booking, cancellation and refund adjusting both in one transaction rather than two systems reconciled later.
-
Three platforms, one small team, two years
Shipping to iOS, Android and the web with a small team usually means one platform leads and the others fall behind, until they behave differently enough that support becomes guesswork.
What we did
A cross-platform front end over a shared API with all booking and payment logic on the server, so the three clients cannot drift apart on the rules that matter.
Architecture
How it fits together
Simplified — the shape of the system rather than every service in it.
-
Clients
- Cross-platform mobile
- iOS build
- Android build
- Responsive web
Native apps for both stores alongside a responsive web app, so a member books from a phone and a studio owner manages the timetable from a laptop without relearning the product.
-
Gateway
- REST API
- Authentication & roles
- Idempotent booking endpoints
One API surface handles authentication, member and studio roles, and every client request — with the booking endpoints written to be safe against retries and double submission.
-
Services
- Booking engine
- Rule engine
- Memberships & packs
- Payments
- Notifications
Each concern separated, so booking rules, entitlements, billing and messaging can be changed or extended without destabilising the others.
-
Data & infrastructure
- Relational database
- Scheduled jobs
- Local cache on device
Bookings, entitlements and payments in one relational store so they can be changed together in a single transaction; scheduled jobs handle renewals, reminders and waitlist promotion.
The decision that shaped everything else: booking rules and entitlements live on the server, never in the app. A client can be wrong about what it shows; it can never be wrong about what it booked.
Solutions
The parts that make a booking platform work
Booking looks simple from the outside. Most of the build went into the rules underneath it — who may book, when they may cancel, and what that does to a payment.
-
Timetable and booking
Studios publish classes once, with room, instructor and capacity. Members browse by day, studio or discipline and book in a couple of taps. Full classes open a waitlist that promotes automatically when someone cancels.
-
Memberships and class packs
Recurring memberships, fixed class packs and pay-as-you-go, each with its own booking entitlements. The app knows what a member is allowed to book before it offers them the button.
-
Payments and checkout
Card payments for memberships, packs and single classes, with renewals, refunds and failed-payment handling. Balances stay consistent whether a class is cancelled by the member or by the studio.
-
Member app for iOS and Android
One cross-platform codebase producing native apps for both stores: upcoming classes, booking history, remaining credits and a profile that remembers a member's usual studio.
-
Studio and instructor tools
The studio side manages the schedule, instructors, rooms and pricing. Instructors get the attendee list for their next class and can mark who actually turned up.
-
Reminders and notifications
Push notifications and email for confirmations, reminders before a class, waitlist promotions and schedule changes — the messages that used to be sent by hand.
Key capabilities
What it does day to day
Five capabilities, each closing one of the gaps above.
| Capability | Runs | Refresh | What it does |
|---|---|---|---|
| Class timetable & booking | Member | Real time | Browse by day, studio or discipline and book in two taps, with waitlists when a class is full |
| Memberships & class packs | Recurring | Per cycle | Memberships, fixed packs and single classes, each with its own booking entitlements |
| Payments & reconciliation | Automatic | Per transaction | Card payments, renewals, refunds and pack balances kept consistent with bookings |
| Studio & instructor tools | Studio-managed | On publish | Publish the schedule, manage rooms and pricing, see who is coming to the next class |
| Reminders & notifications | Automatic | Scheduled | Confirmations, pre-class reminders, waitlist promotions and schedule changes |
Integrations
How the moving parts plug in
Payments, notifications and calendars reach the platform through one API layer rather than sitting beside it as separate tools.
Connected capabilities
- Card paymentsMemberships, packs, single classes
- Push notificationsReminders and waitlist promotion
- Email deliveryConfirmations and receipts
- Calendar exportBooked classes into a member's calendar
Platform integration layer
- REST APIOne contract for every client
- Auth & rolesMembers, instructors, studio owners
- Idempotent transactionsSafe against retries
Core services
- Booking engine
- Rule engine
- Entitlements
- Payments
- Notifications
Because entitlements and payments resolve against the same services, a member buying a pack, booking four classes and cancelling one is a single consistent story rather than three systems to reconcile.
Security & data
What protects member and payment data
The platform holds member details, attendance history and payment methods, so protection was designed in rather than added before launch.
-
Payment handling
Card details are handled by the payment provider and never stored by the platform. The app holds a reference, not a card number.
-
Role-based access
Members, instructors and studio owners reach only what their role requires, enforced on the server rather than hidden in the interface.
-
Attendance privacy
Who attended which class is visible to the studio that ran it and to the member themselves — not across studios on the platform.
-
Transaction integrity
Every booking, cancellation and refund is written as one transaction, so a failure cannot leave a place reserved but unpaid.
The brief
Studios were running on spreadsheets, DMs and paper
Independent fitness and yoga studios rarely have a booking system. The timetable lives in a spreadsheet, class changes go out on social media, memberships are tracked by hand, and payments get chased one message at a time. That holds together until a studio adds a second instructor and a second room.
Peach set out to replace all of it with one product: a member app for finding and booking classes, and a studio side for publishing the timetable and handling memberships and payments. Both had to work on phones and in a browser, because studio owners do their admin on a laptop and their members book on the way to class.
- One timetable, published once, visible everywhere
- Members book and cancel without messaging anyone
- Memberships, class packs and single classes in one checkout
- Instructors see who is coming before the class starts
What made it harder than a calendar
- 01Booking rules differ per studio: cut-off times, waitlists, late cancellation
- 02Payments, refunds and class-pack balances have to reconcile exactly
- 03Two app stores and a web app, kept in step from one codebase
- 04Gyms and studios have poor signal, so the app cannot assume a connection
Process
A two-year engagement, not a two-month build
Peach engaged us from January 2021 to January 2023. The product went live well before that, and the rest of the time went into the things you only learn once real studios are using it.
-
Discovery and product definition
We worked through how studios actually run a day: who edits the timetable, what happens when an instructor is ill, how a late cancellation should be treated. Those answers became the booking rules.
-
Interface design
Booking had to be faster than sending a message, or members would keep sending messages. We designed the member flow around that single test, then designed the studio side for speed of editing rather than beauty.
-
Cross-platform build
One codebase for iOS, Android and web, with the booking and payment logic on the server so all three behave identically. That is what kept a small team shipping to three platforms at once.
-
Payments, testing and store release
Payment paths were tested against the awkward cases — refunds, failed renewals, cancellation inside the cut-off — before we took the apps through App Store and Play review.
-
Live, then improved
With studios using it daily, the work moved to waitlist behaviour, notification timing, reporting for owners, and the steady maintenance of two app stores that change their rules every year.
Technology
Chosen to keep one team shipping to three platforms
A cross-platform front end over a shared API, so a booking rule is written once and behaves the same on an iPhone, an Android phone and a laptop.
Mobile
- Cross-platform framework
- Native iOS build
- Native Android build
- Push notifications
Web
- Responsive web app
- Studio admin
- Component library
Backend and data
- REST API
- Relational database
- Scheduled jobs
- Role-based access
Payments and operations
- Card payments
- Recurring billing
- Refunds and credits
- Error monitoring
Business impact
What changed for the studios
Beyond the headline figures, three things studio owners noticed first.
-
Evenings back
Confirming bookings by message was an evening's work for a busy studio. The app does it, and the owner stops being the booking system.
-
Fuller classes
Waitlists promote automatically when someone cancels, so a late drop-out becomes a filled place instead of an empty mat.
-
Predictable revenue
Memberships renew and packs reconcile without anyone chasing, which turns irregular payment collection into recurring income.
The result
A studio can publish a timetable in the morning and take bookings by lunch
Peach went live on iOS, Android and web with the booking, membership and payment flows in one product. Studios stopped running their schedule out of a spreadsheet, and members stopped asking whether there was space in the six o'clock class.
The engagement ran for two years, which is the part we would point to. Studios kept using it, Peach kept investing in it, and the client rated the work 5.0 in a verified review on Clutch.
- Live on the App Store, Google Play and the web
- Booking, memberships and payments in a single product
- Two years of continuous delivery with the same team
- 5.0 rating in a verified, client-written Clutch review
Where we would start on a similar product
- 01Booking rules first — they decide the shape of everything else
- 02Payments and entitlements together, never bolted on later
- 03One codebase across platforms while the team is small
- 04Ship to a handful of real studios before adding features
Client review
What the client said about the work
Published on Clutch, where the client is verified and we cannot edit or remove what they write.
-
Mobile App Development
Custom Mobile App Development for a Fitness Booking Platform
Overall, we were pleased with the collaboration and the final product delivered.
Erik Falkeskog
Founder & Project Owner, Peach Jan 2021 – Jan 2023
Free discovery call
Have an idea? Let's turn it into AI-powered software.
Book a free discovery call with our experts. Share your idea and we will help you shape the scope, timeline and budget, under NDA.
- Free consultation
- NDA before we talk
- Transparent estimate