Case study: Athleex, a SaaS with a mobile app
How we built our own product for personal trainers: a web platform, iOS and Android apps, subscriptions and push notifications. The choices, the mistakes and what we'd do again.
At a glance
- Product
- SaaS for personal trainers and coaches, with an app for athletes
- Platforms
- Web, iOS and Android
- Technology
- Next.js, PostgreSQL via Prisma, Capacitor
- Infrastructure
- European servers (Hetzner) run by the group
- Releases and data
- CI on GitHub Actions, nightly off-site backups
- Live at
- athleex.com
What problem does Athleex solve?
A personal trainer's job doesn't end at the gym door. There are programmes to write and update, progress to track, messages at all hours, payments to chase and new enquiries to call back. Most of it ends up scattered across spreadsheets, chat threads and notes on a phone.
The biggest cost is the one you don't see: an athlete who quietly stops training and drifts away. By the time you notice, it's too late. Athleex exists to put the coaching work and the business numbers in one place, and to spot who's about to leave before they do.
A trainer doesn't lose a client in a day. They lose them over weeks of silence nobody measures.
What does the product do?
Athleex is a SaaS for personal trainers and coaches, with an app for their athletes. The trainer works from the web platform; the athlete gets the programme on their phone and follows it day by day.
Next to the coaching sits the business. If you sell memberships, you live on recurring revenue and churn, and those numbers belong where the work happens, not in a spreadsheet at month end.
- Training programmesWritten by the trainer, delivered to the athlete in the app.
- Profiles and progressEach athlete's history in one place.
- Public pageFor capturing new enquiries.
- Business dashboardRecurring revenue, churn and customer lifetime value.
- Churn RadarFlags athletes at risk of dropping out, early.
- Athlete appOn iOS and Android.
How is the architecture put together?
One web application in Next.js, with a PostgreSQL database accessed through Prisma. The interface is multilingual, which costs far less to plan from day one than to retrofit once every string is scattered through the code.
It runs on European servers (Hetzner) that we manage ourselves, so we decide where the data lives and how the infrastructure grows. Every change goes through automated CI on GitHub Actions before it reaches production, and the database is backed up nightly with a copy kept off-site.
None of this is glamorous, and that's the point: a SaaS that bills every month should be boring exactly where customers never look.
- Application
- Next.js
- Database
- PostgreSQL, via Prisma
- Languages
- Multilingual interface
- Servers
- European (Hetzner), run by us
- Releases
- CI on GitHub Actions
- Backups
- Nightly, with an off-site copy
Why build the iOS and Android apps with Capacitor?
The Athleex platform is a web app. To get onto phones we had two options: rewrite the product in Swift and Kotlin and keep three codebases in step, or bring the same codebase to the phones. We went with the second, using Capacitor.
Capacitor wraps the web app in a native shell and connects phone features such as push notifications and in-app purchases through native plugins. A new feature is written once, for the web and the phones, by the same team.
The trade-off is in the native details: permissions, notifications, payments and app review follow Apple's and Google's rules, not the web's. That's where we learned the most.
One codebase for web, iOS and Android: one team, one way of working, one place to fix things.
What did the app stores teach us?
Three lessons, all from the iOS app and all learned from real problems. They apply to any app that sells subscriptions or sends notifications.
A review rejected over in-app purchases
Apple rejected a version under its in-app purchase rules, App Review Guideline 3.1.1. We added in-app purchases with StoreKit 2, Apple's framework for payments inside apps, and the version was approved. The lesson: decide how people pay inside the app before your first review, not after.
Push notifications: three causes, not one
Push notifications weren't arriving on iOS. There were three causes, independent of one another: configuration, permissions and delivery. Fixing one wasn't enough, because the other two were still there: each has to be checked on its own.
Currency and iCloud Private Relay
With iCloud Private Relay, a user's country can show up as somewhere else. Pick the currency from the IP address alone and some people see prices in the wrong one: it has to be decided with judgement, not just from the IP.
The app stores aren't the last step. They're part of the product, with rules of their own.
Why do the business numbers live inside the product?
Because anyone selling memberships lives on recurring revenue and churn, and those numbers are needed where the work happens every day. The Athleex dashboard shows recurring revenue, churn and customer lifetime value.
The Churn Radar goes a step further: it flags athletes at risk of dropping out early, so the trainer can get in touch before it's too late. It's the same thinking we bring to startups: the metrics that matter (MRR, churn, lifetime value, explained in our startup glossary) should sit in front of the people who can change them.
What would we do again, and what would we do sooner?
We'd do almost all of it again. A few things, though, we'd do earlier.
We'd do again
- One codebase for web, iOS and Android, with Capacitor.
- European servers we run ourselves.
- Automated CI and nightly backups with an off-site copy.
- A multilingual interface.
- Business numbers inside the product, not beside it.
We'd do sooner
- Settle in-app purchases before the first Apple review.
- Treat push notifications as three separate problems from the start.
- Choose the currency logic before showing a single price.
These are the same choices we bring to startup projects, from SaaS development to app development for iOS and Android. Athleex is live at athleex.com, and its place in the group is on the Athleex brand page.
Questions about Athleex
What is Athleex?
MPN Group's SaaS for personal trainers and coaches, with an app for their athletes: training programmes, profiles and progress, a public page for enquiries, a business dashboard and the Churn Radar. It's the group's own product, not something built for a client.
What technology is Athleex built with?
The platform is a Next.js web app on PostgreSQL (via Prisma), hosted on European servers run by the group. The iOS and Android apps are built with Capacitor on the same web codebase, with automated CI on GitHub Actions and nightly off-site backups.
Why did Apple reject the app?
Over its in-app purchase rules, App Review Guideline 3.1.1. We added in-app purchases with StoreKit 2 and the version was approved.
What is the Churn Radar?
The Athleex feature that flags athletes at risk of dropping out early, so the trainer can step in before they stop. It sits alongside the dashboard showing recurring revenue, churn and customer lifetime value.
Could you build something similar for my startup?
Yes: it's the work we do with startups, from SaaS to mobile apps. Get in touch and we'll start from your case.
Want to build your own SaaS, with or without an app?
We reply within one business day.
Let's talk