Multi-tenant SaaSFitnessPayments

Holloway Studios // Fitness & wellness SaaS

A multi-tenant SaaS platform for a boutique fitness studio chain

Next.js 15Supabase RLSStripe BillingStripe ConnectTwilioVercel
14
studios on the platform by the end of beta
22% → 4%
share of classes running under capacity despite a full waitlist
9 hrs/week
saved per studio on manual instructor-payout calculations
01 — The brief

The client ran 8 studios using a mix of Google Calendar, spreadsheets, and manual SMS reminders. Class scheduling, waitlists, membership billing, and instructor payouts were all handled separately per location — with no unified reporting, the owner couldn't compare studio performance or automate even the simplest processes.

When the client started fielding requests from other studio chains (“can we get something like this too?”), it became clear the internal tool had the potential to become a standalone product. But the internal version had been built for a single company — no multi-tenancy, no data separation between organizations, and no billing system for onboarding new studio clients.

02 — What we built

The product surface

A production-grade SaaS platform with three interfaces on a single codebase.

01

Studio admin panel

Managing schedules, instructors, pricing plans, attendance and revenue reporting, and custom branding (logo, colors) for the member-facing app.

02

Member-facing app

Booking classes, an auto-promoting waitlist, attendance history, and managing the subscription and payment method.

03

Instructor portal

Their own class schedule, attendance stats, and a transparent breakdown of payouts based on classes actually taught.

04

Billing engine

Tracks two separate entities: the studio's subscription to the platform (Stripe Billing, plans tiered by number of locations/members) and instructor payouts (Stripe Connect, automatic splits based on attendance plus each studio's compensation rules).

05

Waitlist automation

When a booking is cancelled, the system automatically offers the open spot to the next person in line via push/SMS with a 15-minute confirmation window, then moves to the next candidate if it expires.

03 — Architecture and stack

Decisions, not just dependencies.

Every studio client runs on shared infrastructure and a shared codebase, with Supabase Auth and Postgres Row-Level Security tying every record to a studio_id — data isolation is enforced at the database level, not just the application layer. Postgres holds the schema covering studios, locations, classes, bookings, memberships, and waitlists, and the frontend is a single Next.js 15 (App Router) codebase running three separate experiences (admin, member, instructor) that share components and a design system.

The billing layer runs two flows side by side: Stripe Billing for studio subscriptions to the platform and Stripe Connect for instructor payouts and split payments. Supabase Realtime drives live waitlist updates, with Twilio (SMS) and Resend (email) handling reminders and waitlist offers. Everything is hosted on Vercel with Supabase managed Postgres and automated preview deployments on every PR.

04 — Delivery highlights

What was hard, and how we shipped it.

  1. 01

    Database-level tenant isolation

    Every record tied to a studio_id with Postgres Row-Level Security — data isolation enforced at the database level, not just the application layer, and confirmed at 100% by an independent security review before public launch.

  2. 02

    Dual payment model

    Two parallel money flows in one system: studios paying a subscription for the platform (SaaS revenue via Stripe Billing) and instructors getting paid based on class attendance (marketplace-style logic via Stripe Connect).

  3. 03

    Recurring billing and dunning

    Studio members pay monthly membership fees by card, with retry logic for failed payments, dunning reminders, and automatic access suspension.

  4. 04

    Real-time waitlist automation

    When a member cancels, the open spot is automatically offered to the next person on the waitlist with a limited confirmation window — cutting classes running under capacity from 22% to 4% despite a full waitlist.

  5. 05

    Verified billing edge cases

    Load-tested multi-tenant isolation and verified billing edge cases — failed payments, partial refunds, mid-cycle plan changes — before the public beta launch.

Looking at a project that sits at this kind of seam?

Bring us the architecture, the constraints, and the ship date. We will bring the rest.