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.

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.