Iron Institute - the live independent-gym build that runs on one stack under the gym’s brand
A live, end-to-end build for Iron Institute, a 24/7 unstaffed independent gym choosing to run on one platform under the gym’s brand rather than the five-SaaS-subscriptions-stitched-together pattern that’s standard in the trade. The public marketing site is live; the underlying platform - 24/7 access record, member management, recurring billing rail, retention loop, branded iOS app - runs against a documented phase plan with the foundation phases in production.
Live: ironinstitute.co.uk
The brief
The off-the-shelf 24/7 gym stack is the “five SaaS subscriptions stitched together” tax: a booking surface, a separate access-control surface, a separate billing surface, a separate email-marketing surface, a “branded” member app that’s actually a vendor template with the gym’s logo on it, and a separate retention-analytics surface on top. None of the five surfaces talks to the other four cleanly. The door says the member’s lapsed but the billing tool says paid. The app shows a class that’s been cancelled. The retention-analytics surface only sees what the email tool exports. The 06:30 access queue at the door isn’t a queue because the gym is busy - it’s a queue because the access drift between two vendors hasn’t reconciled overnight.
The brief was the opposite: one stack, one record per member, one brand on the app the member opens, and the operator’s own software estate scaling with the gym rather than against the vendor’s per-member margin model. The operational moments to design against are specific and concrete: the 06:00 access reconciliation that has to land before the 06:30 queue arrives, the lapsed-member retention conversation that has to surface in the September re-engage window, the failed-direct-debit recovery that has to fire the same hour the bank flagged the failure (not three weeks later), the four-rated vendor-app problem that’s costing the gym brand every time a member opens the app in front of a friend, and the seasonal content cadence that has to feed the local-search surface on the rhythm Google Business actually rewards.

What we built
The public marketing site. ironinstitute.co.uk - fast, statically generated, with the operator’s brand on every surface: home, about, classes, membership, facilities, first-time-visit, FAQ, contact, shop, terms, privacy, 404. Brand-led typography (the discipline of a gym that doesn’t want to look like a clinic), photographed-on-site imagery rather than stock-gym hero shots, structured-data surface for the local-search visibility the gym buys members through.
The single source of truth on member state. One record per member that the door reads, the billing rail writes, and the app reflects - so the “door says lapsed but billing says paid” disagreement closes by construction rather than by an overnight reconciliation script. The record holds membership state, joined date, PAR-Q, emergency contact, opt-ins, the recurring-billing rail position, the latest access events, and the per-member communication thread.
The 24/7 access bridge. The on-site door / turnstile hardware integration bridges to the same member record the billing rail writes. Entry / exit events feed back to the member record live, so the “is the gym busy right now” surface and the 06:00 reconciliation both run off the same data rather than off two vendors that need to be talked into agreement overnight.
The recurring billing rail. The membership rail runs as a first-class part of the platform - recurring DD memberships against the member record, with the failed-DD recovery firing the same hour the bank flagged the failure, the retention triggers (no visits in 21 days, third class missed in a fortnight, month-13 renewal at risk) firing on the member’s own thread, and the renewal conversation landing before the member is already in a “thinking about cancelling” moment.
The member-side portal and the branded iOS app. The member-side surface - account, payments, class bookings, PAR-Q refresh, access status - lives in a member portal and in a native iOS app that’s listed in the App Store under Iron Institute rather than under a vendor’s name. When the member opens the app in front of a friend at the gym, the app store says Iron Institute, the icon is the Iron Institute brand, the splash screen is the Iron Institute identity, and “powered by [vendor]” doesn’t appear anywhere.
The inbound triage line. A trained inbound layer handles the “how much is membership”, “do you have a free pass”, “can I bring a guest”, “is the gym busy right now” questions across voice, web chat, WhatsApp, SMS and DM, in the gym’s voice, trained on the gym’s own pricing and policy, escalating to the operator when the situation needs a human.
The seasonal content cadence. The content cadence runs the New-Year / spring-onboarding / September-back-to-routine cycles on a rhythm the local-search surface rewards, with the publishing chassis under the gym’s brand on the platforms the gym’s catchment actually uses.

The outcome (in studio voice)
The build is designed to do specific things. Described in direction-not-numbers shape - what the build does, not what was achieved:
- Access drift between the door and the billing rail is reconciled by 06:00 daily so the 06:30 queue at the door isn’t a queue caused by “the door says lapsed but the billing tool says paid”. The same record drives both surfaces.
- Lapsed-member retention surfaces the September re-engage conversation that previously stayed unsurfaced, by firing the no-visits-in-21-days and third-class-missed triggers early enough to catch the lapsing member before the gym sees a churn event.
- Failed-direct-debit recovery fires the same hour the bank flagged the failure, not three weeks later, with the member-side message landing in the thread the member already uses for the gym.
- The branded-app moment lands as the gym’s brand, not the vendor’s. When the member opens the app in front of a friend, the App Store listing, the icon, and the splash all say Iron Institute - the trust signal lands as the gym.
- The single source of truth closes the door-vs-billing disagreement by construction rather than by an overnight reconciliation script that has to talk two vendors into agreement.
- The five-subscriptions-stitched-together cost shape collapses to one platform under the gym’s brand, scaling with the gym rather than against the vendor’s per-member margin model.
Specific £ / % / time-saved figures attributed to Iron Institute are deliberately omitted here. Outcome detail will be published with named-client permission as it lands.

Which verticals this fits
- Gym fitness - primary
- Gym fitness / personal-trainer spoke - the diary + member-record + class-booking shape, lighter sibling
- Clinics - treatment-plan member pattern (the member record + recurring-billing rail ports)
- Pet services - daycare-member pattern
- Hospitality - loyalty / repeat-guest membership pattern
- Cross-vertical mobile-app references - any vertical where a branded customer-facing iOS app under the operator’s brand is the right shape; the Storytimebaker chassis sits underneath
Which problems this solves
- Trainable Inbound AI Agentthe inbound triage line in the gym’s voice (membership pricing, free-pass, guest, busy-right-now)
- Recurring Service Recallthe member-retention cadence + the renewal-at-risk trigger
- Customer & Third Party Portalthe member portal + the staff-side admin
- Content & Portfolio Cadencethe seasonal content cycle that feeds the local-search surface
- Resource & Waitlist Yield Recoverythe class-waitlist auto-promote (the no-show / waitlist-offer-up loop)
- Multi Channel Comms Threadone thread per member across SMS, app push, and the WhatsApp number members already text
Want a build like Iron Institute for your gym?
Tell us what the current “five SaaS subscriptions stitched together” tax is in your business - what each surface costs, where the disagreement between two vendors shows up in the member experience, and which of the operational moments (the 06:00 reconciliation, the September re-engage window, the failed-DD recovery, the branded-app moment) the build needs to land first. We’ll come back with a sketch of what we’d build, what would live on one platform under your brand, and what the build would look like at your scale. No demo, no calendar widget. Email reply, scoped sketch, you decide. Send an enquiry.