Holloway Studios // Fitness & wellness SaaS
A multi-tenant SaaS platform for a boutique fitness studio chain
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.
The product surface
A production-grade SaaS platform with three interfaces on a single codebase.
Studio admin panel
Managing schedules, instructors, pricing plans, attendance and revenue reporting, and custom branding (logo, colors) for the member-facing app.
Member-facing app
Booking classes, an auto-promoting waitlist, attendance history, and managing the subscription and payment method.
Instructor portal
Their own class schedule, attendance stats, and a transparent breakdown of payouts based on classes actually taught.
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).
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.




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.
What was hard, and how we shipped it.
- 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.
- 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).
- 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.
- 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.
- 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.

