LIFT

RoleFounder · Product, Design, Engineering

PlatformiOS · Expo / React Native

Timeline4 months

StatusShipped · v1.0, updates ongoing

BuiltSolo

A muscle-building coach that shows its work. Every decision explained in plain language, and traceable to your training data.

Lifters who’ve trained a few years stall, and can’t tell if they need more volume or less. Tracking apps don’t answer that. Coaching apps do, but hide their reasoning, so people override them the first time a call feels wrong. My first build had streaks and badges. Testers said those got in the way of what they wanted: seeing real progress.

I set one rule: the app can only say what it can back up with your logged workouts. Streaks came out. Praise too, unless the data earned it. Assisted pull-ups were the hard case. Progress there means less weight, which breaks every strength score. I tried two other metrics. Both misled anyone losing weight. So I removed the score and explained why.

A weekly review that explains what’s changing and why, per muscle group. An onboarding flow that ends in a program with the reason behind each choice. Feedback that updates next week’s plan the same day. All three are one rule in different places. And I wrote tests that fail the build if any screen shows a claim the data doesn’t support.

LIFT is on the App Store. Of the 45 lifters who tested it pre-launch, about 80% finished the two-week trial and wanted to continue. One wrote: “It feels as if I have a real coach because it’s based on feedback from what I log and it doesn’t feel scripted.” Some found it too hard, a couple wanted more. Progress tracking is next, same rule.

That feedback reset the project. I’d built the first version around consistency: a streak for showing up, a badge when you kept it. Testers wanted something else. They wanted to feel progress two ways, in the numbers on screen and in how a session felt. A congratulations message spoke to neither.

So the question changed. It stopped being how to keep people opening the app and became how to make the app’s advice worth following. My bet was simple: people would follow a program if they could see why it was built that way, and could check that reasoning against their own logs.

The rule sounds obvious written down. In practice it cut a lot. Streaks were already built and working, and removing them felt like removing the fun part. But testers had told me the fun part was in the way. A streak rewards showing up. The data can’t say anything about showing up except that you did. Streaks are on hold until I can find a version that passes the rule, if there is one. The social layer I’d planned is gone. I couldn’t make it say anything the logs could back.

Praise was the subtle one. Most fitness apps congratulate you for opening them. Under the rule the app can say your bench went up only if it did, and stays quiet otherwise. Quiet turned out to be fine. It made the rare praise mean something.

The pull-up case was where the rule got tested for real. Every strength score assumes more weight is progress. On an assisted pull-up machine, less assistance is progress, so the score runs backwards. I tried inverting it and I tried scoring bodyweight-relative load. Both produced numbers that looked like regression for anyone whose bodyweight was dropping, which is a lot of people in a cut. A wrong number is a claim the logs don’t support. So those exercises show no score, and a short line explains why the usual math doesn’t apply. That was the moment I knew the rule was doing its job: it made me delete something rather than ship a plausible lie.

The tests exist because the rule is easy to break by accident. A copy tweak can turn “your volume went up” into “great work,” and only the first one is something the logs can stand behind. I didn’t trust myself to catch that in review every time, so the build catches it.

I also built the whole thing. Normally this is where a product designer hands off to a developer. I didn’t, because I used AI to do the work a developer would usually take over: the React Native code, the App Store submission, the updates that have shipped since. Every automation had me reviewing it before it went anywhere. So brand, product management, design, and engineering all sat with one person for four months. That’s also why the rule survived. It’s much harder to hold a constraint like this when it has to be re-argued at every handoff.

The quote is the result I care about most. “Doesn’t feel scripted” is someone describing the rule without knowing it exists. They didn’t say the app was smart or motivating. They said it was based on what they logged, which is the only thing I asked it to be.

The split matters more than the number. Too hard and too easy at the same time means the reasoning landed but the load calibration didn’t. That’s a tuning problem, not a trust problem, and it’s a better problem to have. It’s also the first thing progress tracking has to address: the app needs to see how a block actually went before it can decide how hard the next one should be.

Four months, first commit to App Store. The constraint I set to keep myself honest turned out to be the thing users noticed. I’ll take that into whatever I build next.

Previous work iPrevail

LIFT on a gym floor, showing today's Upper Body session and why this week looks the way it does

Three LIFT screens: sessions, progress, and coach feedback with reasoning

LIFT coach review, week 9: what changed and why, with a plain-language reason on every muscle

LIFT landing page sections: plenty of apps change your workout, this one tells you why; enough to grow, not more than you can recover from; log, rest, repeat; straight answers; stop guessing.

80%

Finished the two-week trial and wanted to continue

92%

Of early lifters completed their first program

100

Downloads in the first two weeks after launch

The LIFT landing page on a desktop display: LIFT looks at every set you log, works out what next week should be, and shows you the reasoning. Every time.