An operations platform for a boutique fitness studio chain across multiple branches

The challenge

A boutique fitness studio chain runs scheduled, capacity-limited class sessions across multiple branches. Each class has 20-40 bookable spots, a roster of instructors, a per-branch schedule that changes weekly, and members who buy class packs, redeem promotional codes, and accumulate loyalty status that affects their priority on the booking calendar.

The pre-existing setup was a patchwork:

1. Booking lived in a third-party tool. Spot allocation, waitlist, cancellations, and member-pack drawdown were handled by a SaaS not built for the brand's mechanics - promotional codes had to be applied manually by front-desk staff, loyalty tier overrides could not be expressed at all.
2. POS was a separate system. Front desk transactions for retail, drop-in classes, and merchandise lived in a generic POS. Reconciling daily takings against class attendance was a manual end-of-night exercise per branch.
3. No single operator view. Each branch ran on its own calendar, its own roster spreadsheet, and its own cash float report. Headquarters had no consolidated view of attendance, churn, instructor utilisation, or revenue per branch - and the numbers it did get were always days late.

For a brand whose entire member experience is built on getting a spot in a popular class on time, the operational friction was real - and the missing analytics meant the team was making merchandising and scheduling decisions blind.

The approach

We ran a four-phase engagement and shipped two surfaces in parallel - a web admin platform for studio and headquarters teams, and a mobile app for members.

• Discovery (3 weeks). Workshops with the operations lead, two flagship studio managers, and the head instructor. Output: a written process map of every member touchpoint, a target operating model, and a phased build plan with milestone-based pricing.
• Foundation sprint (3 weeks). Auth, multi-branch tenancy model, member identity, the class-session domain model, mobile project skeleton with TestFlight and Play Internal Testing pipelines. The boring parts done right before any feature work.
• Feature sprints (16 weeks). Two-week cadence. Booking, schedule management, staff management, POS, vouchers and promotions, and the loyalty engine - shipped in two parallel tracks (web + mobile) with a shared API.
• Branch rollout (8 weeks). Phased rollout one branch at a time, with each studio team trained in person and the previous system decommissioned only after one full week of parallel running.

The key architectural decision: model the class session as the central object, with member spots, instructor assignment, waitlist position, payment line items, and loyalty earn/redeem all as state transitions on that one entity. Promotions and vouchers became filters that applied at the session-payment join, so a rule like "members on tier B get one free booking per week, but only at off-peak sessions" was expressible without bolt-ons.

The outcome

• One platform across web and mobile. Studio teams run the day on the web admin; members book, pay, and track their pack balance on the mobile app. Same data, same source of truth.
• Branch-aware operations. Schedule, staff roster, cash float, and merchandising inventory all scoped per-branch - with consolidated views for headquarters that update in real time, not at end-of-day.
• Vouchers and promotions that the marketing team can configure themselves. Eligibility rules, expiry windows, member-tier targeting, single-use codes, bulk-generated codes for partnerships - all in a self-service interface, no engineering tickets.
• Loyalty mechanics that reflect the brand's actual member economics. Tier qualification on rolling class attendance, priority booking windows by tier, redemption against class packs and retail, all under one engine.
• End-of-night reconciliation collapsed from manual to automatic. POS transactions, attendance, and pack drawdown reconcile against each other and surface anomalies before the next morning's shift.

Specific numbers are withheld at the client's request.

Tech stack

Next.js · React Native · TypeScript · NestJS · PostgreSQL · Redis · Stripe · AWS · Sentry.

Why this matters for multi-branch service operators

If your business depends on selling time slots - fitness classes, treatment rooms, restaurant tables, advisory appointments, court hours - the platform decisions are similar. Off-the-shelf booking software handles the easy 80%: list of slots, customers click, payment goes through. The hard 20% is what makes a brand differentiated.

The 20% is the policy surface: how loyalty tiers affect booking priority, how multi-branch members move between locations, how a promotion lives alongside a member pack, how a cancelled class refunds against the right pack, how end-of-night reconciliation actually closes per branch. That logic does not live in any SaaS configuration UI. It lives in your operating model, and a generic product cannot express it without contortion.

When that 20% drives more retention than the easy 80% does, building is correct. The architecture above - class session as the central object, branch as a scoping dimension, every commercial mechanic as a state transition on the session - generalises to most multi-branch slot-based operations.

If that sounds like your situation, book a 30-minute scoping call.