A fitness app, three versions in
A long-term project from someone who's been training for over ten years. Here's what each version taught me.
Visit the live site (opens in a new tab)Launched
2020
Status
Live
Last updated October 2026 About an eight-minute read
This case study looks back at the work I've done on KEEP.FIT, my own fitness app, built alongside client work. It's written for anyone thinking of hiring me, and for anyone planning to build an app of their own. It shows how I work - what I'd build again, what I'd cut, and what I'd tell you before you start. And most of what I learned came from getting things wrong, which is far cheaper to read about than to repeat.
At a glance
Seven years, three versions
-
2019
The idea
A consistent plan for whatever equipment the gym has.
-
2020
Version 1
The app provides the workouts.
-
2021
Version 2
Pick a workout, or build your own.
-
2025
Version 3
Daily challenges and streaks.
-
Next
Version 4
Simpler, and more focused.
2019
How it started
I started building KEEP.FIT when I set up OLXR at the end of 2019. The idea came from my own time in the gym. I've been going for over ten years, and I follow CrossFit and sport more generally. I'm analytical about workouts, and I wasn't after a personal trainer - I already knew how to do the lifts and movements, and I'm self-motivated, so I didn't need someone to motivate me. I was far more interested in optimising my efficiency and my movements.
What I wanted was to be efficient when I got there: a consistent plan I could follow with whatever equipment the gym had.
The mission
I wanted an application to help me optimise my time in the gym.
The goal
Build the framework, and have the app provide the workouts for users.
The plan was for KEEP.FIT to provide the workouts. Then COVID arrived while I was building it. Nobody was going to the gym, I built a home gym myself, and I tried to reshape the app around that part-way through the build. Changing the specification mid-build was ultimately the problem with version 1.
There was a second problem. I'm not a personal trainer. I can optimise my own workouts, but optimising them for other people inside an app was much harder. I was trying to build a recommendation algorithm on what users told me, and that information isn't always accurate - it could mislead a personal trainer reading it, let alone an algorithm.
Animated workouts
We tried creating animations for no-equipment workouts, so we could programme a workout and still give people visual cues - something that's easier with animation than with video. I worked with animators to create an animation for each exercise, built to blend into the next: one continuous workout, whatever order the exercises came in.
I ended up dropping it. I wanted users to pick from around 10 avatars - different genders, ages, hairstyles. Across every exercise, that becomes a big animation job, and far too expensive.
The goal
Let people pick a workout, or build their own.
In version 2, there were workouts to pick from, and if you didn't like them you could change them or create your own. I set my own workouts, so I assumed other people would want to do the same. They didn't. The usage numbers showed it: people opened the app and looked for a workout, and if they couldn't find one, they left.
We also tried machine learning in version 2. The problem was that we weren't getting enough users to get valid, real-world information back to train the models.
Generating revenue
Version 2 was when I started charging - the plan had always been a monthly subscription. But Stripe doesn't work with Isle of Man companies, and I wanted a payment provider people recognised. PayPal was an option, but it took users off the site to pay, which I didn't want.
While I worked out how to use Stripe, I tried other ways for KEEP.FIT to make money. I looked into gym apparel and ordered just over 100 pieces of gym clothing. They're in a box somewhere. It pulled me away from the app: chasing several revenue streams, the KEEP.FIT machine becomes far too large for one person to run.
In the end I restructured the business to be able to use Stripe. Users got a 30-day free trial, then paid monthly. Frustratingly, very few converted.
In between
Talking to trainers
“I could optimise my own time in the gym. How do you optimise everyone else's?”
I could optimise my own time in the gym. The question was how to build the tools to optimise other people's time in the gym - and the answer I came up with was community. Trainers would put their plans on, users would find them, and if they liked the workouts they'd contact the trainer for a personal plan. That part would happen away from the site. KEEP.FIT would be where people found each other.
The trainer side came out of letting users create their own workouts. There were two types of account, user and trainer. It was never trainer software in the sense of managing clients - it was "this trainer suggests this workout".
I spoke to a number of personal trainers. Some were understandably cautious - there was a worry that an app like this might train people instead of them. That was never the intention: I wanted to work with trainers and give their clients a smoother experience. Online training is different from one-to-one training, and online trainers can reach far more people, far quicker.
-
Step 1
A trainer posts a plan
It says who built it.
-
Step 2
A user finds it and joins the schedule
Discovery happens on KEEP.FIT.
-
Step 3
They connect with the trainer
The trainer builds a following, or offers that user personalised sessions.
The goal
Get people coming back for five minutes a day, Wordle-style.
Version 3 introduced challenges: small daily movements that people could build streaks on. The inspiration was Wordle - open the app, spend five minutes, keep your streak going.
It was also the first version to use AI: we used an automation tool called n8n to run different AI models that built workouts from anonymised user profiles. That got round the version 2 problem: the AI models didn't need our own data to learn from. They drew on other sources.
But again, it was difficult to tailor these to the user, because we still didn't have enough users. That's very difficult when you're not a personal trainer and can't hand-hold users through the journey. Ultimately, I can't give personalised fitness advice that scales to hundreds of users.
What I wanted to build was a community that built and shared workouts they enjoyed.
The fitness industry is very competitive, and the problem I still have to solve is user retention.
“Looking back, KEEP.FIT's failures come down to ease of use and focused problem solving.”
Get those right, and people stay and the community grows over time.
The numbers
- 1,000
- exercises, every one linked by hand
- 25-50k
- visits a month from search
- ~500
- users at the peak
Fitting it around client work
Everything was done in sprints, and contract work nearly always runs in sprints too. I might be on a client project for three months, then pick KEEP.FIT up for a couple of weeks while the client reviewed.
In my spare time I was using the app myself, so what I learned in the gym fed back into it.
The two weeks fall while the client reviews.
What lasted
The exercise library
Built from 2020 and all the videos recorded. That was two years before ChatGPT, so it was all done by hand: 1,000 exercises, each linked to the equipment it needs, a description, the muscle groups it works, and alternatives. It has been used in every version since.
We started using AI in late 2022, but the human-written information was still better. Modern AI has got much better.
The domain
keep.fit now ranks well on search engines and gets 25,000 to 50,000 visits a month from search - something we didn't have in the early days, and something version 4 starts with.
A product of its own
KEEP.FIT's social media pages needed graphics constantly, and that's where RepeatPosts came in.
How I built RepeatPostsMistakes
These are the mistakes I made along the way. I'd rather share them than hide them - each one taught me something, and those lessons are shaping version 4.
-
Mistake
I changed the specification mid-build.
COVID made it feel necessary.
Lesson
Always write the specification before the code.
-
Mistake
I assumed everyone wanted to build their own workouts.
I set my own, so I took it as read that others would.
Lesson
Watch what people actually do, rather than what you would do.
-
Mistake
I chased several revenue streams at once.
Just over 100 pieces of gym clothing, still in a box somewhere.
Lesson
One person can only run one machine. Finish the product first.
-
Mistake
I tried machine learning before there were users to learn from.
Not enough real-world information was coming back to train anything.
Lesson
Earn the data before you build on top of it.
-
Mistake
I optimised load speeds and wording before the journey worked.
Lesson
Make the path right first. Making it quick is the easy half.
What's next
So why keep it live?
Simpler, and more focused
Built on the lessons from versions 1, 2 and 3. More to share when it's ready.
In progress
What I'd tell you
If you're building your first app
-
Research your market
Understand what your competitors are doing.
-
Understand your user
Just because you want an app that does something doesn't mean everyone else needs it to do the same thing.
-
Don't optimise straight away
We spent a long time on load speeds and wording, when we could have spent it on the user journey.
-
Get live quickly
Prototype, and get live as quickly as possible.
Other products
- manx.directory The Isle of Man's business directory Read the case study
- RepeatPosts Social graphics that stay on brand Read the case study