← All projects
Case Study · 02 · Computer Vision · Fitness
Apex
An AI strength coach built the way a real coach works: diagnose first, prescribe second, watch every rep.
Case Study · 02 · Computer Vision · Fitness
An AI strength coach built the way a real coach works: diagnose first, prescribe second, watch every rep.
Artifacts
Four of the 79 boards, exactly as they were designed in HTML before implementation started chasing them. Click any frame for the full capture.
Assessment · Step 1
The Spine · Active Workout
The Verdict
Delight · PR
The Thesis
Most fitness apps hand you a template and count your sets. A real coach does something else entirely: they watch you move, they know how you slept, and they can tell the difference between a muscle that is weak and one you simply don't know how to use yet.
Apex encodes that judgment. It tracks training with the phone camera on a tripod, reads recovery from real-life signals, and runs an assessment before it ever writes you a program.
"The active workout tracker is the product; everything else is icing."
Apex build bible, DESIGN-SPEC.md
Process
The interesting part of Apex isn't just what it does, it's how it was built. The product was designed on paper (well, in HTML) before the implementation was allowed to chase it:
79 screens were designed as clickable HTML boards before the redesign touched the app, so every flow got argued about while it was still cheap to change.
A single DESIGN-SPEC.md rules the build: a north-star thesis, the information architecture, per-screen behavior, an exact design-token system, and a file-by-file translation plan into the codebase.
Design decisions cite published interaction research (Apple's Human Interface Guidelines, Material 3, Nielsen Norman Group, Laws of UX) and teardowns of Strong and Hevy. Taste arguments become evidence arguments.
Development moves in numbered waves, twelve and counting. Each wave ends shippable and verified on a physical iPhone before the next begins.
The Engine
The program engine is pure ES-module JavaScript with no runtime dependencies, one entry point, and around 300 automated tests. Call nextWorkout(program, history, profile, signals) and it produces the next session of a personalized mesocycle: double progression on reps then load, RIR ramps across the block, weekly volume held between researched landmarks, stall detection, and automatic deloads when the signals call for one.
Because the engine is platform-agnostic, it runs identically under Node for testing and inside React Native on the phone. The same inputs always produce the same program, which is what makes 300 tests meaningful.
Assessment
Apex's most distinctive idea is an exploration phase that runs before programming begins. A screening battery watches how fast each movement pattern improves. Rapid early gains signal a recruitment or skill gap (you had the strength, you just couldn't access it), while slow, grindy progress signals a genuine strength deficit.
The distinction matters because the fixes are different: practice versus volume. The profile that falls out of the assessment is exactly what the program engine consumes, so the diagnosis literally writes the prescription.
The Camera
The camera feature started as a research question: wearables or vision? Vision won on setup friction and information density, and BlazePose (33 tracked joints) won the bake-off. The same MediaPipe pipeline serves web and native by running inside a WebView bridge, with raw landmarks posted back to the app's kinematic layer.
Accuracy is framed honestly in-product with confidence bands rather than false precision. A camera that guesses should say so.
Signals
Apple HealthKit feeds the engine sleep, HRV, daily movement, and body-composition trends. Recovery flexes training volume while load stays deliberately steady, so a rough week shrinks the session without erasing your progress.
State lives in an offline-first Supabase backend with server-set roles and row-level security, synced with a debounce so devices converge without fighting. The app works fully offline; the cloud is a convenience, not a dependency.
Verification
Around 300 node:test cases across 33 files pin the engine's behavior. Roughly 15 Maestro flows drive the real UI end to end. Release builds run standalone on a physical iPhone against the live backend, and every wave ends with that device check before new work starts.
The open frontier is on-device camera capture performance, and it's tracked as a research task with explicit success criteria rather than a hope.