Work · Product ยท Gym operations SaaS

ClubOS

An operating system for gym chains: door access, charges, messaging, personal training and daily operations in one multi-tenant platform, built in weekly slices.

Role Architect and builder (Agile Tech Solutions)When 2026
ClubOS
16 slicesshipped in about six weeks; each one vertical, end to end and in production within a week
~5 sfrom signup to a working tenant on its own subdomain
2 peopleneeded to approve any charge over the threshold
0card numbers in the browser: Stripe payment tokens only

The problem

A gym chain runs on a pile of separate tools: one for memberships and direct debits, one for the doors, a couple for email and text messages, another for staff announcements, and spreadsheets for personal training and rotas. The front desk switches between tabs all day, owners reconcile charges at the weekend, and nobody can see that the same member has just walked into two sites at once.

The idea

ClubOS is one operator's console that sits on top of the systems a chain has to keep (the membership and direct-debit platform, and the door-access system) and replaces the rest: occupancy and access, charges, messaging, personal training, support tickets, daily opening and closing checklists, and reports.

One design choice shaped a lot of it: personal trainers are treated as tenants rather than staff. They rent space, so bookings, conflicts, no-shows and chair rent are tracked per trainer.

How it's built

ClubOS was built in slices: one vertical, end to end, in production within a week. Sixteen slices shipped between March and April 2026, from the foundations (sign-in, members, access, PT, tickets, dashboard) to charge governance, messaging, operations runs, reports, per-tenant branding and self-serve signup.

It is multi-tenant from the ground up. Each chain gets its own subdomain, resolved from the hostname on every request, and a new tenant is provisioned about five seconds after signup. Branding (logo, colours and hero copy) is stored per tenant and applied through CSS tokens. The front end is Next.js, the API is FastAPI on asyncpg and PostgreSQL, with Redis, MinIO for files and Caddy at the edge.

The changelog: sixteen slices, each shipped end to end in production within a week.

Where the risk is: money and doors

In a gym the risky moments aren't logins; they're money and doors, so that's where the controls are. No card data ever reaches the browser: payments use Stripe tokens only. Any charge over a threshold is held until a second operator approves it, and every pound taken, reversed or refunded has an audit trail.

Door events arrive as webhooks from Kisi, and each one is verified with an HMAC signature before it's accepted. Access intelligence flags anomalies such as one member entering two clubs at the same time. Staff sign in with passwordless magic links (hashed, single-use tokens), device registration is throttled, and an emergency on-call roster uses its own narrowly scoped token.

Where it doesn't fit (yet)

ClubOS is a pilot-stage product, built around a six-club UK chain, and it has the rough edges that implies. Membership data from Gymflow arrives through a 15-minute Zapier poll rather than in real time. Single sign-on, SCIM provisioning and white-label domains for larger groups aren't finished. The status page is reported by staff rather than backed by full monitoring, and sign-in emails have no retry queue yet.

What I took from it

Shipping in weekly vertical slices kept every feature honest: each one had to work end to end in production before the next began. And the identity lens carried straight over from enterprise work: find where authority and money actually move, and put the second pair of eyes and the audit trail there.

Building something that has to be secure by design?
I help teams get identity, secrets and AI access right from day one.
How I work with teams →