Most Fitness Apps Replace the Trainer. We Kept Him.
How a small gym in Novi Sad went from a website brief to an online training business, without turning the coach into a content library.
The exercise library in this app is admin only. Short clips, fifteen to twenty five seconds each, one movement per clip. No member has ever seen it, and none of them ever will.
In most fitness apps that library is the product. You browse it, you filter it, you pick a plan, and the videos are what you paid for. Here it is a tray of parts that exactly one person touches: the trainer, when he sits down to write your week.
That inversion is the project. Everything else is plumbing.
The Brief That Changed
Nikola Matić has been training people for years and runs a small gym on Podbara in Novi Sad. Two rooms, 140 square metres, group sessions capped at five people, plus one to one and boxing. He came to me for a website.
We kept talking. The website was real work and he needed it, but the more interesting question was what he did with the people who found him and did not live in Novi Sad. He was turning that away.
So the scope changed. Not "build a site", but "build a site, and then build a second business that does not exist yet, and make it feel like the first one."
Who Writes the Program
Pick any fitness app and look for where the plan comes from. Almost always it is generated: something reads your goal, your level and your equipment, then assembles a plan out of a template library. The human on the marketing page is a face, not an author. That is not a criticism. It is the only way to serve a million people.
Nikola serves dozens, and he writes every program himself.
There is no template table in the database. There is nothing to clone. When a new client starts, he opens the builder, picks them, and writes their program a day at a time: this exercise, these sets, these reps, this much rest, this note, these two joined into a circuit. The next client gets a different one, built the same way, from nothing.
New work unlocks weekly, so it is ongoing authorship rather than a download. The intake questionnaire and the twenty minute call before anything gets built feed him, not a recommendation engine.
The software's job is narrow and it is not glamorous: hold his library, let him assemble a day quickly, deliver it to the right phone, and keep track of who has paid. He is not competing with an algorithm, and the app is not pretending to coach anybody.
Four Steps, and the Order Mattered
We shipped in four passes. Each came out of a conversation rather than a roadmap, and each only made sense because the one before it existed.
The website
What he asked for, and still the thing that does the selling. Separate pages for group training, individual training and the online program, cross linked so each one hands you to the other two. This stayed a normal, fast, public website, and that mattered later.
The video programs
The product that did not exist yet. Per client programs behind a login, with video served through signed links that expire after an hour, so a shared URL is worth nothing by the time it gets passed around. This is where the business changed shape.
The app
Near enough every member is on a phone. The member area installs to the home screen, and once installed it drops the marketing header and footer so it behaves like something he handed you rather than a page you bookmarked. The public site deliberately stayed out of it. Turning the whole site into an app would have cost the search traffic the business runs on.
Booking
The step that closed the loop. Members pick a slot inside the same app, five people to a session, cancel up to a day before. It started as a convenience for the people already training in the room. It turned into the bridge: someone who found him online, bought a program and lives three hours away can now book a real session in the actual gym when they are in town.
That last one is why these are a sequence and not a feature list. The online business and the gym stopped being two businesses.
All of It Is One Plugin
Everything custom on this project lives in a single WordPress plugin. It holds the exercise library, it is the builder where he writes programs, it signs the video links, and it runs the booking. That is the entire bespoke surface.
Nothing else is custom. The theme is stock, the page builder is stock, and authentication is entirely WordPress's own. Logins, password resets, session cookies and the reset email all belong to the CMS, and the plugin never touches any of them.
The reason is practical rather than clever. Anything custom is something that can break, and when it breaks there is no staging site, no second developer and no support queue. There is me, in the evening, with the client waiting. So the rule was to keep the custom part as small as the job allows, and let the CMS do everything it already does well.
Logins are the clearest case. WordPress has handled them for millions of sites for twenty years. Replacing that with something of our own would have added a way to fail and bought us nothing.
Booking was the same decision a second time. It could have been an off the shelf plugin, and two decent ones were on the table. It became part of the plugin we already had, because a separate one arrives with its own idea of what a member is, its own login and its own look, and we would have spent the time gluing the two together instead.
What the Position Costs
Three constraints shaped nearly every technical decision.
Then the list of things we did not build, most of which took longer to decide than to skip.
That last one is my favourite. Access does not lapse on a date. He flips it himself. Automatic expiry would eventually lock out somebody who paid on time while he was busy on the gym floor, and that failure is far worse than the one it prevents.
What I Actually Did
I should be straight about my role, because it is not the one people assume when they hear "custom plugin".
I am not the programmer. I work in QA, and on this project I was also the product owner. The code was written with an AI assistant. What I brought were the two things it could not: deciding what should exist, and checking whether what came back was actually right.
Product. Nikola knows his business inside out and could not have told you what to build, which is normal and is the entire reason the role exists. The online programs were not in the brief. Neither was booking. Both came out of sitting with him and asking what he turns away, what eats his evenings, and what he wishes he could say yes to.
Then the harder half, which is saying no. Everything in that skipped list started as a reasonable request or a tempting idea. The manual access toggle is the one I argued hardest for, against automating it, because I could picture the afternoon it locks out somebody who paid on time while he is on the gym floor with his phone in a locker.
Testing. This is my actual trade, and it is what made working this way safe. AI produces a lot of code quickly and it always looks right. That is the trap: the automated checks confirm the code is valid, never that it does what anyone wanted. So all of it got tested by hand, the way I would test anybody's work. On a real phone. As a member, then as the trainer. In the states nobody demonstrates.
That is where the interesting failures were. A dropdown that opened with nothing in it, so the trainer could reach for the control and move nobody. Panels that shipped open, turning one screen into several thousand pixels of scrolling. A message telling a member their session had been moved when it had not. Every one of those passed the automated checks without complaint, and two of them I found by looking at the screen.
Then I turned that into something repeatable, because doing it by hand on every deploy does not survive contact with a real week. A throwaway sandbox boots the real CMS and a real database, on the production theme, in the gym's own timezone, and runs four suites and 147 assertions against it. Both of those details are deliberate rather than tidy. A suite passing on a default theme in UTC would pass happily while production was broken, because every booking deadline is measured in local time and the theme's own layout rules have broken this member area before.
Anything that only lints is not tested.
The copy is the one place the AI stayed out entirely. Nikola has a hard rule about the site text: no em dashes, no AI vocabulary. He can recognise machine writing, he does not want it on his site, and he is right that the people he sells to would notice it too.
The Ceiling, on Purpose
This does not scale infinitely, and that is the design rather than a flaw waiting to be fixed.
His hours are the ceiling. Writing a program by hand takes the time it takes. The software raises the ceiling by deleting the paperwork around each client. It cannot remove the ceiling, because the thing being sold is his attention.
If someone offers you an app that scales personal coaching to unlimited clients, they have quietly removed the coach.
That may be a perfectly good product. It is a different one.
The Short Version
The brief was a website. What it became was a way for one person to keep doing the thing he is good at, for more people than a room holds, without turning himself into a content library.
If you want the testing side of how I work with AI written code in more depth, that is in From One Giant Skill to an AI-Powered QA Team.
WordPress with a custom plugin, an installable member area, signed video delivery and a booking module. Product, testing and delivery by me, the code written with an AI assistant.
September 2026