RepFlow.
A workout tracking application designed and built around the way I actually train: planned in advance, logged mid-set, and used in the gym rather than at a desk.
- Mobile first
- Persistent sessions
- Installable PWA
- Role
- Product Designer / Developer
- Focus
- Product Design / Front-End / PWA
- Status
- Active product
Overview
RepFlow started as a personal solution. Most workout applications ask for a subscription, carry features I do not use, or push training into a workflow someone else designed. Instead of continuing to adapt to another product, I built the one I wanted, then kept building until it was a real one: a public product page, an installable application, and a training history I rely on.
AI-assisted development accelerated the build, but the product requirements, interaction design, state architecture, and quality bar were mine to define and defend. That ownership is the point of this case study: the decisions below are product decisions with engineering consequences, made and lived with by one person.
The Challenge
Logging a set has to take seconds. Weight, repetitions, and progression through a routine had to happen with minimal taps and no reading.
A workout in progress cannot disappear. A reload, a backgrounded tab, or a dropped connection had to leave the session intact.
Training changes in the moment. Swapping an exercise or reordering the rest of the session had to be possible without abandoning the workout.
The product is used one-handed, standing, mid-set. Targets and primary actions had to be designed for thumb reach, not a desktop pointer.
Gym connectivity is unreliable. The application and the active session had to stay usable when the network does not.
Depth without clutter. Routines, notes, timers, and history had to exist without pushing complexity into the workout loop.
Approach
One loop was protected and everything else built outward from it. Each decision below pairs a product position with how it was actually executed.
- Core loop
- Built around plan, start, log, adjust, finish. Nothing shipped unless it served that sequence.
- Mobile first
- Controls for real gym use: fast taps, one-handed reach, interruption treated as normal rather than an edge case.
- Persistent state
- Workout continuity as a product requirement, not an implementation detail. Sessions restore in place.
- Constraint-driven planning
- Sessions generated around available time, muscles, energy, and equipment, with a review step before anything starts.
- Progressive delivery
- Phased build: the core workout loop first, then history, then installation and offline behavior on top of a product that already worked.
- Real usage
- Used during actual workouts, with friction found there fed straight back into product decisions.
The Product
Active Workout
The screen the product lives or dies on. A reload restores the session in place, set completion is a single tap, and the rest timer stays pinned above the finish action so nothing important leaves the thumb zone.
Sets can be added, dropped, or marked as warm-up and failure mid-session, and per-exercise guidance references recent comparable sessions rather than a generic template.
Planning & Generation
Training rarely matches an ideal plan, so the product starts from constraints: muscles, session length, equipment, and energy produce a workout sized for the day, reviewable before it commits.
Progress
Logged work only matters if it comes back as context. Weekly volume, training insights, and personal records are derived from sessions, never entered by hand.
Install & Reliability
Installation, data ownership, and update behavior are product surfaces, not settings buried in a menu. Install instructions live in the product, backups can be exported or restored, and the running version sits next to browser and connection state.
The marketing site and the installed application ship from the same build, with the progressive web app opening directly into the training experience.
Reliability & Delivery
The engineering decisions that keep a gym session intact, in the order they matter.
- Persistent sessions
- An active workout survives navigation, a reload, or a backgrounded tab, so a gym session is never lost to a browser event.
- Local-first state
- Browser storage is authoritative for the primary workout experience. The gym never depends on a network round trip.
- Backup model
- Supabase is used for snapshot backup and explicit restore, deliberately kept out of the critical workout loop rather than acting as live sync.
- Update safety
- Progressive web app updates are prompt-based, so a new deployment can never force a reload during an active workout.
- Offline behavior
- The application stays usable in poor gym connectivity and through interrupted network conditions instead of failing at the moment it is needed.
- Validation
- Validated across common iPhone sizes, with automated test coverage expanded throughout development alongside each phase of the product.
Results
Stack and Systems
- React
- TypeScript
- Progressive Web App
- Service worker
- Browser storage
- Supabase
- Snapshot backup and restore
- Automated testing
- Responsive validation