The most complete thing I have built is for AD Personal Training, a personal trainer based at Gym One in Dumbarton. It is two products rather than one: a public website whose job is to turn visitors into consultations, and a members-only app that clients use between sessions.
These are notes on the decisions that mattered. No numbers, because the honest ones are the client's to share, not mine.
The website and the app want opposite things
This was the first thing to get straight. A marketing site is read once by a stranger deciding whether to trust you. An app is opened four times a week by someone who already has. Optimising both for the same thing would have made both worse.
So the public site is built around one action - booking a free consultation - with the proof a stranger needs nearby: testimonials, transformations, where the gym actually is on a map. Everything else got cut or pushed down.
The app assumes none of that. It is a tool for someone who already knows where they are going.
Why it installs from the browser instead of an app store
The members app is a progressive web app. It installs to the home screen, sends push notifications and runs full screen, but there is no App Store or Play Store listing.
That was deliberate, for a single-trainer business:
- No review queue. A fix ships when it is ready, not when someone approves it. For a business where the developer and the support line are the same person, that matters more than it sounds.
- No two-platform tax. One codebase covers iPhone and Android. For a client at this scale, building the same app twice would have been most of the budget.
- No install friction. A new client taps a link and is in. Asking someone to find you in a store is a step where people quietly drop out.
The trade-off is real and worth stating: you give up store discovery and some deeper device integration. For a trainer whose clients all arrive through him personally, store discovery was worth nothing.
Passkeys, because gym hands are wet
Sign-in uses passkeys and biometrics through WebAuthn. Partly that is the security answer - there is no password to reuse, phish or leak.
But the reason it earned its place was more ordinary. People open this app mid-session, standing at a rack, often with a phone in one hand. Typing a password in that context is genuinely annoying, and anything annoying enough gets skipped. A thumb print is not.
A lot of good technical decisions look like this: the security benefit justifies the work, and the usability benefit is what makes people actually use it.
The features that were harder than they looked
Barcode food scanning
Scanning a barcode to log a meal sounds like a small feature. It is a camera permission, a scanning library, an external food database, and a pile of failure cases: unknown product, no signal, wrong result, permission denied. The happy path is a morning. Everything else is the work.
Progress tracking over time
Recording a weight is trivial. Making a year of weights meaningful is not - people miss weeks, weigh at different times, and any honest graph has to be readable when the data is messy. The design question is what you show someone on a bad week, which is a product decision more than a technical one.
Coach and client messaging
Private messaging inside the app was the feature most likely to sprawl. It got deliberately kept small: a coaching feed and direct coach-to-client messages, and nothing resembling a social network.
Privacy was a feature, not a compliance chore
The public site runs on essential cookies only, with no third-party trackers. That is partly principle and partly the nature of the data: the app holds weight, body measurements and wellness notes. That is health information about identifiable people, and it should not be casually flowing to advertising networks.
Deciding this at the start is cheap. Retrofitting it after you have wired in four analytics tools is not.
What I would do the same, and what I would not
Same: building it as a web app; splitting the public site and the member app cleanly; getting the consultation booking flow right before anything else; keeping the messaging deliberately boring.
Differently: I would define what "done" meant for the app's first version harder and earlier. When you are building for one motivated client, every conversation surfaces a good idea, and good ideas are exactly what extends a timeline. That is a scoping discipline problem, not a technical one, and it is the thing I watch for now.
Why this is the only case study on the site
Because it is the only build of this size that is live and mine end-to-end. I would rather show one real project properly than pad a portfolio with concepts.
You can see the full case study, including the feature list for both halves, or tell me what you are trying to build.