How We Built the Software That Turned a Gym Chain Into a Subscription Business
Ionio partnered with Fit24 to build the software that turned a bootstrapped Taiwan gym chain
into one connected network, and added a recurring revenue stream it never had before. We
delivered one membership that opens any location, with booking, training and
rewards in a single app.
The founder had spent close to two decades in fitness and no time in software. We were the
only technical arm of the company, taking the idea from a blank page to a production-ready
platform that earns like software rather than a set of separate rooms.
Brooke Daye, Founder and CEO of Fit24, on working with Ionio.
The Expensive Problem
A Chain That Could Only Grow One Building at a Time
At Ionio we run every project through a two-layer framework. Layer one asks how the work helps
users do something meaningfully better. Layer two asks how solving that creates compounding
value for the business. Fit24 had a sharp problem on both.
Layer 1
The people using it
Brooke ran a small chain of gyms in Taiwan, and each one worked as its own
island. A membership only opened the door of one location. To book a trainer you had
to catch the front desk, and to sign up you filled in a form and waited in a queue. Nothing a
member did at one gym followed them to the next, and none of it left the business anything it
could reuse. It was clumsy for the gym-goer, and for the operator every step of it ran on
staff time at a desk.
One Card, One Door
Same card, next gym
The same card at the next gym, and the door stays shut.
Layer 2
The business underneath
The deeper problem was how the chain could grow and what it earned while it did. A gym chain
makes money one way, memberships sold against physical floors, so it grows one lease
at a time at the cost of each lease. Every new location is another fit-out and
another front desk. Brooke wanted more than a bigger version of that. He wanted the chain to
run as one connected network instead of 4 separate rooms, and he wanted it to earn in ways
a room full of equipment cannot, from digital content, from rewards that bring members back,
from a subscription that renews on its own.
What One More Gym Costs
Paid again every time
Every new location is another fit-out and another front desk.
None of that runs on the software a gym business has, because a gym business has almost none.
Turning a chain into a connected, subscription-led platform takes a member app, a trainer app, a
booking engine that respects 100 trainers across 4 locations, payment rails, content
delivery and a QR entry system, and Fit24 had no technical capability to build any of
it.
The gap between 4 gyms and 1 business was an entire category of software.
Why This Was Hard
The Difficulty Was in the Parts You Cannot See
We started Fit24 in September 2021 with an idea and nothing else. No wireframes, no scope, no
real sense of how big the thing was. The hard parts were not the screens. They were
underneath.
One membership that has to work across separate businesses
Core
A single subscription had to open any location in the chain, which sounds simple and is
not. Each gym has its own members, its own trainers and its own schedule, and the
platform has to treat them as one network while keeping them as separate books. A
booking at one gym, a check-in at another and a plan that spans both had to stay
consistent no matter which location a member walked into. Getting that
multi-tenant model right was the foundation everything else sat on, and
it had to be correct before a single booking could be trusted.
What this meantOne network on the surface, four separate books underneath.
A hundred trainers who must not be in two places
Complex
This was not one gym with a timetable. It was around a hundred trainers working as
temporary staff across four locations, each setting their own hours. A member booking a
slot needed a trainer who was free, at that gym, with enough of a gap to have physically
travelled from the last session. A trainer free on paper fifteen minutes away is not
free if the previous session only just ended. Encoding that travel buffer into
the availability logic meant the booking engine had to reason about time and
distance together, not just an open slot.
What this meantAvailability had to account for the drive, not just the diary.
Software that has to open a real door
Physical
A booking on a phone had to end with a magnetic door opening in the real world. That is
a different class of risk from anything on screen. If the booking logic is wrong a member
sees the wrong time, but if the entry logic is wrong a paying member is locked out of a
building at eleven at night with no staff there to help. The QR entry tied our software
to hardware we did not build, from a manufacturer we reached through a translator, and it
had to work every time because the failure was somebody standing in the cold.
What this meantA bug here does not show an error. It locks someone out.
Money and access flowing to temporary staff
Trust
A hundred contractors getting booked and paid is not just a schedule, it is a question of
trust the platform has to enforce. A trainer had to be approved before they could take a
booking, so a submission went to Fit24’s own staff for sign-off before anyone
appeared to a member. Underneath that sat the logic for who is allowed to work, who gets
paid for what, and how a session that did not happen is handled, all of it running
through an unfamiliar payment system built for a market we did not operate in.
What this meantNobody reaches a member until a human signs them off.
An idea, not a specification
Scope
The brief was a sentence about booking training sessions. Underneath it sat two apps, an
admin backend, a booking engine, payments, content and door entry. We had to draw the
whole system before we could size it, then architect all of it on a fixed price and a
fixed timeline, where every gap in the brief was a decision that came out of our
own margin.
What this meantDraw the whole system before anyone agrees a number.
A single booking touched four locations, a hundred contractors, a payment system in another
language and a door in the physical world.
After William Hogarth, Marriage A-la-Mode: 2, The Tête à Tête, about 1743. National Gallery, London.
The Philosophy
Priced Like Property, Worth Like Software
A business is valued for what it is, not for what it owns. A set of gyms is a set of gyms, each
one its own rooms, its own members, its own desk, and the market prices them as exactly that.
Connect them and the business becomes something else. One app, one membership
that works everywhere, one account that follows a member between locations, and separate rooms
turn into a single network.
That was what Fit24 was reaching for. Not a bigger chain but a connected one.
Once a member belongs to the network rather than a building, the business can add what a single
gym never could, content to train with at home, rewards that pull members back, a subscription
that renews on its own. Each layer earns on top of the memberships the floors already bring in,
and none of it needs another lease.
Separate, they are worth a row of gyms. Connected, they are worth a business.
A chain grows by opening rooms. A platform grows by connecting the ones that exist, and earns
from recurring revenue that compounds, because a member tied to a network stays longer
and spends across more of it. That steadier revenue is what a buyer reads as a real
business rather than a handful of gyms.
The same logic reaches past gyms. Any operator with a physical footprint and repeat customers
can connect what they run and add a layer that earns the way software earns. A clinic group, a
tutoring chain, a network of salons. The locations keep doing what they do, and
the platform over them turns scattered sites into one business. That is where
our Prescriptive Intelligence work goes next, encoding what a business already knows and running
it as the layer that changes what it is worth.
One booking touches both apps. A member finds a gym and requests a trainer, the trainer
accepts it on their own app, and a scanned code starts the session. Here is that flow from
both sides.
The Member App
01 / The Home Screen
Every location on one map
The app opens on a first-name greeting and the member’s plan, Membership with PT, over
a live map with the Fit24 locations pinned on it. A selector at the top steps through the
gyms in the chain, Gym Three, Gym Two and on, so one login moves between every site
the membership covers. The shortcuts underneath go straight to the things a member
does most, Show QR to get through the door, View Trainers and View Gyms.
02 / The Gym
A location you can look inside
Opening a gym pulls up its own sheet. Real photographs of the floor, the address, and the
trainers who work there. Two ways to book sit at the bottom, Pre Book to
reserve a session ahead and Quick Book to take a trainer who is free now. A
member sees the room and the people before committing to either.
03 / Booking a Session
Pick a time, pick a trainer
Booking runs as a short flow. First a calendar at the chosen location, with a start and end
time for the session. Then the trainers available for that slot, each one a member can open
and book. The date and the trainer are chosen in sequence, so a member only ever sees
trainers who can actually take the time they picked.
04 / Confirmed
The request goes in
Once the slot and trainer are set, the member gets a clear confirmation, the trainer’s
name and the exact session time. The booking is now a request sitting with the
trainer, not a finished transaction, which is where the second app picks it up.
The Trainer App
05 / The Trainer’s Day
Requests land here
A trainer signs in to their own app and lands on a home screen built around their work, a
running count of sessions completed and, below it, the bookings members have requested. Each
request card carries the member, the location and the time, with a tick and a cross to
accept or decline in place. The member’s booking from the last step
shows up here as a live request.
06 / Accepted
The two sides meet
The trainer accepts and the booking is confirmed for both of them. From here
the trainer’s History tab holds every approved session, member, location and time, each
with its own QR ready for the session itself.
07 / Starting the Session
A scan ties it to the real world
When the session begins, the trainer opens the scanner and reads the member’s QR code
to start it, Scan QR Code to Start Session. The booking that began as a tap on a map
ends as a scan that marks the session live, the same QR mechanism that gets a member
through the door in the first place.
The Solution
What We Built
Ionio owned the full arc: product strategy, design, wireframes, UI and UX, the build,
deployment and the handover at the end. Five systems carry the platform,
spread across two apps and the admin behind them.
01
The Member App
The front door for a gym-goer. A member finds the nearest location on a live map, subscribes
to a plan inside the app, books a trainer and follows workouts on the days they train at
home. Everything a member does with Fit24 happens here, with no front desk in the
loop.
Everything In One Place
No desk in the loop
Four things a member does, and not one of them needs a counter.
02
The Booking Engine
The hard core of the product. It checks whether a slot is open at a gym, which trainers are
free in that window and whether a given trainer can physically reach that location in time.
The travel buffer between sessions lives in this engine, which is what lets
100 trainers move across 4 gyms without ever being booked into two places at once.
The Travel Buffer
Can they get there?
A trainer free on paper is not free if they cannot reach the room.
03
The Trainer App
The other side of every booking. A trainer sets the hours they are available, sees the
sessions requested of them, accepts or declines and starts a booked session by scanning the
member’s QR code. Their availability feeds straight back into the engine that
members book against.
Accept, Then Scan
The other side of the booking
The trainer answers, and the scan starts the session.
04
The Rewards and Content Layer
What keeps a member coming back. Check-ins and FitPoints reward turning up and referring
friends, and a library of training videos sorted by level gives members a reason to open the
app between visits. This is the stickiness a room full of equipment cannot
offer, built to make the subscription worth renewing.
Reasons To Come Back
Between the visits
Stickiness a room full of equipment cannot offer.
05
The Staff Backend
The control room. Fit24’s own team approves trainers before they reach the platform,
oversees members and locations and watches how the system is running. A trainer
submits to join, a staff member signs them off, and only then do they appear to anyone
booking.
Signed Off First
The control room
Nobody reaches a member until Fit24 has approved them.
The Results
The Business Impact
Fit24 came to us earning one way, memberships sold at 4 separate desks. It left with a
platform that added several new ways to earn on top of that, all running through a single app.
A subscription that spans every location and renews on its own. Digital content members pay to
train with between visits. Rewards and referrals that bring them back. Where the
business had one revenue line tied to its floors, it now had a connected, recurring one laid
over the top.
The machinery behind that is real, not a slide.
The platform carries one membership across every location, turning 4 separate
gyms into a single network a member pays once to use. Sign-up, booking and payment all happen in
the app, which takes the front desk out of the transactions that used to need staff. A
100 trainers across 4 locations schedule, get approved and get paid through one
system. Every renewal, every piece of content bought and every referral is revenue the chain
could not have earned as 4 standalone gyms.
What the 6 months delivered was a non-technical founder carried from an idea to a
finished, production-ready platform, and a bootstrapped operator handed the software to
run 4 gyms as 1 connected business.
Under the Hood
Technical Infrastructure
The stack was chosen to be ordinary on purpose. Brooke would bring on his own engineers
eventually, and every part of this had to be something he could hire into
rather than a set of choices only we could run.
Mobile
Flutter
Both apps are built in Flutter and run on iOS and Android from one codebase. For a team
of four shipping two apps on a fixed timeline, a single codebase across both
platforms was the difference between hitting the date and missing it.
Backend
Node.js and Express
Runs the booking engine, the availability logic and the account and subscription
handling. Mature and widely documented and staffable almost anywhere,
which is exactly why it was chosen.
Admin
React
The staff backend where Fit24 approves trainers and oversees members and locations.
Built as a straightforward web app so non-technical staff could run day-to-day
operations without going near the apps.
Content Delivery
Cloudflare
Carries the video streaming for the digital content library and sits in front of the
platform as a firewall. Streaming workout videos to members needed a delivery
path that stayed quick under load, and Cloudflare gave us that without standing
up our own.
Cloud
AWS with Docker
Every component containerised with Docker and deployed on AWS. Consistent environments
across the team and room to scale without re-architecting later.
Authentication
Auth0
Handles member and trainer sign-in. A platform holding personal and payment data
needed login done properly from day one rather than rolled by hand, so
we leant on a service built for it.
Monitoring
Datadog
Watches the running system so problems surface as signals rather than as member
complaints.
Landing Site
Webflow
The public-facing site was built in Webflow, quick to stand up and simple for the
client’s own team to edit without an engineer.
Project Roadmap
Our Approach
Six months from an idea to a production-ready platform, planned as four and a half and extended
by one. Four people carried the whole thing.
Execution Timeline — Six Months, 2021 to 2022
Discovery
Architecture
Build
Handover
Phase 1 · Discovery and Design2021
Block diagrams first to see the shape of it
Then wireframes for every screen across the member app and the trainer app and the admin
Then full UI in Figma
Where does the member start, what does a trainer see, what does the staff view need
The brief was a single idea about booking training sessions. We turned it into a
system. Those questions got answered on the board before anyone wrote code.
Phase 2 · Architecture and Integrations2021
We architected the full platform on a fixed price and timeline
Then opened the conversations that sat on the critical path
The part that could not be rushed. The Taiwanese payment provider and the
door-hardware manufacturer both had to be worked out through a translator, and both fed
directly into how the rest of the build could proceed.
Phase 3 · The Build2021 to 2022
The booking engine first, because everything leaned on it, travel buffer and all
Then the member app and the trainer app in parallel
Payments through the Taiwanese provider
QR entry against the magnetic doors
Video streaming for the content library
The staff backend for approvals and oversight
A little over four months with a team of four.
Phase 4 · Extension and Handover2022
A one-month extension carried the platform to production-ready and closed out the remaining work
We handed the codebase over built on ordinary technology the client could hire into
That was the point of choosing the stack the way we did.
Retrospective
What We Learned
I.
You cannot size what you have not drawn
The brief was one sentence and the system underneath it was enormous. We had to draw the
whole platform before we could estimate it, and we still under-read the
scope. On a fixed price that gap comes straight out of your own margin, so the
real work is turning a vague idea into a mapped system before a number is ever agreed.
II.
An integration is only as fast as the partner behind it
The payment provider and the door hardware sat on the critical path and both ran on their
own timelines, not ours. When a build depends on an outside party you do not control,
their delay becomes your delay, and the schedule has to be built with that
slack in it from the start rather than discovering it halfway through.
III.
A language barrier is a technical risk, not just a comms one
Working out an undocumented payment API through a translator is slower and easier to get
wrong than any English-language integration. We treated the translation gap as part
of the engineering risk, not a side issue, and that is the right way to scope any
build that reaches into a market you do not operate in natively.
IV.
Boring technology is a feature
We built on a conventional stack on purpose, so a founder with no engineers yet could hire
into it later. Flutter, Node, React, nothing clever for its own sake. A client who
can only run their product with the original team in the room does not really own it,
and choosing ordinary tools is how you hand over something they can actually keep.
V.
Fixed scope and fixed price is a bet on your own estimate
The commercial shape of this project meant every gap in the brief and every
provider delay landed on us rather than the client. It is a workable model only
when the scoping is disciplined enough to survive the surprises, and this build taught us
how much rigour that front end actually demands.
The Takeaway
Give a business rooted in concrete a software layer, and
you change what it is worth.
Fit24 came to us as a chain of gyms and an idea about booking sessions. What the founder
actually needed was the thing a gym business is not built to make for itself, the software
that turns a set of buildings into a platform. We took that from a blank page to a finished
product, in a market we did not operate in and a language we did not speak,
and handed it over built to be owned by someone else.
That is the work we care about. Not shipping features but finding the layer that changes
what a business is, then building it well enough that the people who commissioned it can
carry it forward without us in the room.
How We Operate
01 // Integration
We work as the technical and product side of your business, not a vendor at arm’s length. The work you just read is how we operate. We build production systems and hand over the knowledge so you own what we made.
02 // Acceleration
We do not start from zero. The patterns we have built across booking engines, subscription platforms and cross-border integrations now shorten every build that follows, so you start from systems that have already been proven rather than a blank page.
03 // Experience
We have been building software for years, across legal, e-commerce, fitness and more. We know where these projects get hard because we have been through the hard parts before, and we scope for them from the start.
When to talk to us
You are sitting on a physical business or a loyal audience or a process you repeat by hand, and you can see that a software layer would change what the business is worth.
What you are missing is the team that can take it from idea to a product you own.
When we’re not a fit
You want a thin wrapper on someone else’s model, AI for the press release, or a feature a big platform will absorb in six months.
We will tell you that directly.
Next Step
Let’s see if there’s a fit
Thirty minutes, no deck. We will talk through your challenge, share some relevant work and
see if it makes sense to build together.
