A workout tracker built for consistency.
Designed and shipped solo on iOS and Android, connecting fast workout logging with companion progression and shared accountability.
Workout tracking has to be quick during a set. A game layer has to create a reason to return without getting in the way of training.
I owned product direction, design, implementation, exercise-data integration, the Firebase backend, and store listings as a solo founder.
Make logging dependable first, then connect completed workouts and consistency to companion progression and Battle Crews.
A working app available on iOS and Android, with a foundation I can keep extending. Store availability is the evidence here; retention and revenue are not claimed.
Real workouts. A world worth coming back to.
CURRENT FLUTTER UI / SAMPLE DATA
From a product idea to iOS and Android.
- shipped product
- iOS + Android
- design through code
- End to end
- founder + builder
- Solo
The problem worth solving
Workout tracking needs to be fast in the middle of a set. Long-term motivation needs something more. The challenge was to connect a dependable training tool with progression and social accountability without letting the game interrupt the workout.
What I owned
I owned the product direction, interaction and visual design, implementation, exercise API integration, Firebase backend, and store listings. Working solo meant every feature also came with a maintenance decision.
The product is the loop.
- 01
Workout
Log sets + repetitions
- 02
Progression
Consistency + streaks
- 03
Companion
A visible sense of growth
- 04
Battle Crews
Shared accountability
A conceptual map of the product relationships, redrawn for this case study.
Three decisions that changed the product.
Make it a good tracker first.
Logging sets needs to work one-handed, with a persistent timer and predictable controls. That interaction earned the most iteration.
- OTHER OPTION
- Lead with the game and build the tracker around it.
- TRADEOFF
- Fantasy mechanics stayed secondary during the core workout.
- RESULT
- A focused logging flow with the progression layer built around real training.
Own the interface to the exercise data.
A third-party library avoided hand-authoring exercise definitions. A normalization layer kept the client independent of the provider.
- OTHER OPTION
- Maintain a custom exercise catalog or couple the client directly to a vendor.
- TRADEOFF
- Maintain a small API layer in exchange for a consistent schema.
- RESULT
- Firebase Cloud Functions cache and normalize exercise data before it reaches the app.
Reward consistency, not maximum weight.
Progress should feel possible for a beginner and an experienced lifter. Raw weight creates the wrong comparison.
- OTHER OPTION
- Base companion progression on personal-record weight.
- TRADEOFF
- Progression celebrates participation rather than ranking strength.
- RESULT
- Weekly streaks and completed workouts connect personal progress with Battle Crew accountability.
A product you can actually use.
From choosing a companion to logging a workout, earning rewards, and showing up for a crew: these eight screens are rendered from the app’s Flutter source. Account-dependent screens use sample data, including shop inventory and prices. The final profile image is an earlier released app capture.
Shipped, with more to learn.
The product shipped to the App Store and Google Play. The existing project record describes ongoing iteration on workout logging, companion progression, and Battle Crews. No new retention or revenue claim is added here.
What the work made reusable
A normalized exercise-data layer, a shared progression model, and a Firebase foundation that supported adding Battle Crews. The product became a working system I could keep extending.
What I would measure next
Next measurement: evaluate the logging flow and the game loop separately. A strong companion experience should bring people back, while a workout remains quick and usable even when they ignore the game.