The Problem
Every workout app we tried got one of two things wrong. The consumer-facing apps (Strong, JEFIT, Hevy) are built for general fitness — they track exercises but do not understand progressive overload as a system. They will record that you benched 185 for 5 reps today, but they will not tell you that your volume load has plateaued for three weeks and suggest a deload. The serious lifting apps assume you already know what you are doing and offer a spreadsheet with a skin.
Our founder is a NASM certified personal trainer who became a software engineer. We know what the training data should look like, what the trends should tell you, and what decisions the data should drive. We built the app we wished we had when training clients — one that understands the science behind programming, not just the numbers.
The Approach
The core data model tracks workouts, exercises, sets, and performance metrics. But the structure goes deeper than most trackers. Each set records weight, reps, RPE (Rate of Perceived Exertion), and rest time. Each exercise has a movement pattern classification (push, pull, hinge, squat, carry) and a muscle group mapping. Each workout has a session type (strength, hypertrophy, deload, test) that affects how the data is interpreted.
Progressive overload tracking is the centerpiece. The app calculates volume load (sets x reps x weight) per exercise, per muscle group, and per movement pattern over time. It detects plateaus — defined as less than 2% volume increase over a rolling 3-week window — and flags them with actionable suggestions based on NASM periodization principles: increase weight, increase reps, add a set, or schedule a deload week.
Most workout apps treat every set equally. But a set of 5 at RPE 8 is fundamentally different from a set of 5 at RPE 10, even at the same weight. Without RPE tracking, your volume numbers lie to you — you might be accumulating fatigue faster than the raw numbers suggest. Building RPE into the data model from day one changed how every downstream calculation works.
Technical Decisions
React Native with Expo over native Swift/Kotlin. The app needs to work on both iOS and Android, and the interface is form-heavy data entry — not the kind of GPU-intensive interaction that demands native performance. Expo's managed workflow handles builds, updates, and device testing without the overhead of maintaining two codebases. For a data-entry app with charts, React Native is the right tool.
SQLite over a cloud database. Workout data is personal and latency-sensitive. When you are logging a set between rest periods, the app needs to save instantly — not wait for a network round trip. SQLite stores everything on-device with zero latency writes. The schema is relational (workouts have many exercises, exercises have many sets), which maps naturally to SQL. If we add sync later, SQLite can serve as the local cache with conflict resolution on merge.
Typed exercise taxonomy. Every exercise in the database is classified by movement pattern, primary muscle group, secondary muscle groups, and equipment required. This taxonomy is not just metadata — it drives the progressive overload analysis. When the app says "your pushing volume has plateaued," it is aggregating across bench press, overhead press, and incline dumbbell press because they share a movement pattern. This is how an actual trainer thinks about programming, and it is what every other tracker misses.
Chart-based trend visualization. Performance trends render as line charts showing volume load over time per exercise and per muscle group, with plateau detection zones highlighted. The charts use the same periodization markers a trainer would draw on paper — mesocycle boundaries, deload weeks, and PR markers. The goal is not just to show data but to make the training story legible at a glance.
What We Learned
The biggest lesson was that domain expertise changes the entire app architecture. If we had built this without the NASM background, it would be a CRUD app with a list of exercises and a history view — which is what every other tracker is. Understanding periodization, progressive overload, RPE-based fatigue management, and movement pattern classification turned it from a data entry app into a training tool. The domain knowledge did not just inform the features; it shaped the data model, the calculations, and the UI decisions.
The second lesson was about offline-first mobile development. Users log workouts in gyms with unreliable connectivity. Building offline-first with SQLite was not a nice-to-have — it was a requirement we would have missed if we had not actually used the app in our own training. Every interaction works with zero network, and the app never shows a loading spinner for local data.
Building a fitness or health app? Book a free call.