Case Study • Fit24
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 Ionio team is just fire. Want something done fast? Yep Yep. Want something cool and innovative? We can do that. Nothing is beyond their reach.”
— Brooke Daye, Founder and CEO of Fit24At 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.
Brooke ran a small chain of gyms in Taiwan, and each one worked as its own island. A membership bought access to a single location. Booking a trainer meant catching the front desk. Signing up meant paperwork and a queue. Nothing a member did at one gym carried to the next, and nothing they did carried into anything the business could reuse. For a gym-goer it was clumsy, and for the operator every one of those steps ran on staff time at a desk.
A chain of four, running at the speed of one counter.
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 four 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.
Every gym pays for itself and nothing pays twice.
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 a hundred trainers across four locations, payment rails, content delivery and a QR entry system, and Fit24 had no technical capability to build any of it.
That is the expensive problem. Not a slow workflow, but a whole category of software standing between a bootstrapped operator and the business he actually wanted to run.
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.
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.
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.
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.
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.
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.
A gym chain and a software platform can hold the same members, the same rooms and the same monthly income, and still be treated as two very different businesses. A gym chain earns one way, memberships against physical floors, and it grows by opening more floors. A platform earns from recurring revenue that renews on its own, and it grows without pouring more concrete each time.
That is the move Fit24 was reaching for. Not a bigger chain, but the same chain run as software. One membership that opens any location turns four separate gyms into a single network. Digital content and rewards give a member reasons to keep paying between visits. A subscription that renews becomes revenue the business can count on rather than a sign-up it has to win again every month. The floors keep earning what floors earn, and a new layer of recurring revenue sits on top of them.
The gyms keep earning what gyms earn. The platform adds a stream that renews on its own.
Recurring revenue changes what a business is, not just what it makes. A buyer, a lender or a partner treats predictable subscription income differently from takings that depend on filling a room each month, because it is steadier and it compounds. This is why the subscription, the content and the rewards matter beyond what they do for any single member. Together they turn a chain of gyms into something that behaves, and eventually gets valued, more like a software business than a property one.
The same logic reaches past gyms. An operator sitting on a physical footprint and a base of repeat customers can usually add a layer that earns the way software earns, on top of what the floors already bring in. A clinic group, a tutoring chain, a network of salons. The building keeps doing what it does, and the software layer over it adds a stream that compounds. That is where our Prescriptive Intelligence work goes next, encoding what a business already knows and running it as the layer that changes what the business is worth.
Prescriptive Intelligence · ionio.ai/prescriptive-intelligence