INDEPENDENT PRODUCT / 02

Reppro

Log less. Know what to do next.

MVP · QA REFINEMENT · PREPARING FOR LAUNCH

How I approached the problem

01Problem
The real problem is not missing training data. Logging happens at the worst possible moment to operate a phone.
View detail — Problem
02Exploration
The core acceptance criterion is no more than three taps and 20 seconds from selecting an exercise to recording a set. Social features, friends, coach matching, real-time AI form detection, cardio, and nutrition are excluded because they require different infrastructure or moderation without directly reducing logging friction.
View detail — Exploration
03Solution
The core path connects routine creation, in-workout logging, rest, and review into one continuous ‘next step’ loop.
View detail — Solution
04Validation
The evidence currently shows that the design and logic are systematically testable—not that market fit or retention has been proven.
View detail — Validation

01 — Overview

I reframed workout logging as a decision tool: finish a set entry in under 20 seconds, then know what to do next.

Reppro is an iPhone strength-training product for self-directed lifters who already train consistently but struggle with logging friction and progression decisions. I own product strategy, UX/UI, the design system, implementation, and final decisions. The MVP is currently in QA refinement and preparing for launch; it has not been publicly released yet.

Role: Solo product designer-developer
Period: 2026
Platform: iPhone · iOS 26+ · SwiftUI
Status: MVP · QA refinement · preparing for launch

A lifter checks Reppro's focused workout view with one hand beside a squat rack — Usage-scenario mockup. The phone shows the actual Reppro interface; the gym environment is a generated reconstruction.

02 — Context

This is an offline MVP built with solo resources, so every feature must justify the product and maintenance cost it adds.

The launch market is Taiwan, Hong Kong, and Macau. V1 is Traditional Chinese and iPhone-only. The product uses SwiftUI and SwiftData, stores everything locally, has no backend or account, and ties subscriptions to the user's Apple ID through StoreKit.

The constraints became prioritisation criteria: one person, no research budget, no behavioural analytics, no server, and no parallel Android, iPad, or web build. Explicit non-goals protected the core workout scenario.

01Solo design and development

02Local-only, no backend

03No account sign-in

04No behavioural tracking

05Traditional Chinese iPhone launch

03 — Problem

The real problem is not missing training data. Logging happens at the worst possible moment to operate a phone.

The primary user trains three to five times a week, understands the exercises, and already follows a split routine. They often rely on paper, Notes, or spreadsheets. The difficulty is not knowing what to record; it is doing so immediately after a set, with sweaty hands, unsettled breathing, and a short rest window.

Multiple fields, page switching, and backfilling later make logging easy to abandon. Without consistent history, progressive-overload decisions become guesswork. I defined the core scene as standing beside the equipment, recording one set with one hand in under 20 seconds, and immediately knowing what comes next.

P0: disciplined intermediate self-directed lifters. P1: beginners who need clear guidance. Explicitly excluded: social features, coach matching, real-time form detection, and cardio tracking.

CORE SCENEOne hand≤ 3 taps≤ 20 secondsBetween sets · sweaty hands

An iPhone on a gym bench shows Reppro's rest timer beside a water bottle and towel — Usage-scenario mockup. The phone shows the actual Reppro interface; the gym environment is a generated reconstruction.

04 — My Role

AI accelerated execution, but problem framing, product trade-offs, design principles, and final accountability stayed with me.

ZEKE / DECISION OWNER

What I owned

Define positioning, target users, and non-goals
Build the information architecture, core flows, and design system
Set priorities, the business model, and acceptance criteria
Review every implemented state and make the final call

AI / COLLABORATOR

What the tools supported

Turn decisions into specifications
Support SwiftUI implementation
Run simulator checks and capture screenshots
Flag specification gaps for a decision instead of deciding autonomously

05 — Discovery

I did not present personal experience as research. I used three repeatable methods to narrow the problem responsibly.

First-hand contextual observation

I broke down my own equipment-side logging context—one hand, sweat, limited rest, and divided attention—and used those constraints as inputs to every interface decision.

State-by-state screenshot review

Every change was run in the simulator and captured for comparison across visual focus, state differentiation, empty states, and design tokens.

Competitor logging-cost audit

I compared the fields, screen changes, and interruptions required to record a set, making logging speed—not feature count—the P0 priority.

The next validation step is equipment-side testing with lifters of different experience levels, focused on one-handed use, logging time, and error patterns.

06 — Strategy

I use continued training in week four as the value signal, while separating free logging from paid decision support.

The north star is week-four retention—not downloads or DAU

Downloads only prove the store page attracted attention, while DAU conflicts with a natural training frequency of three to five sessions per week. Returning in week four is a better signal that a logging habit and useful history are forming. It also creates the basis for older-history limits and Pro value.

Trade-off: The learning cycle is longer, and short-term opens cannot be used to manufacture a growth signal.

Logging speed is P0; every other feature gives way

The core acceptance criterion is no more than three taps and 20 seconds from selecting an exercise to recording a set. Social features, friends, coach matching, real-time AI form detection, cardio, and nutrition are excluded because they require different infrastructure or moderation without directly reducing logging friction.

Trade-off: I gave up more marketable features to build greater depth and offline reliability in one critical scenario.

03 / DECISION REVERSAL

I reversed the original no-purchase decision

V1.0 had no in-app purchase, but that left product maintenance unanswered. V1.1 became freemium: logging stays free forever; Pro charges for intelligent recommendations and reasons, progress insights, multiple routines, and older history.

Paywalling logging is the line I will not cross. If people must pay before they can build history, the product blocks the value it promises.

One-time purchase: revenue becomes disconnected from continuing decision value
Completely free: no sustainable maintenance model
Paid logging: breaks the history-building loop at its source

One Big Card: one visual focus per screen

Lime means the next action; ink means a completed fact

Numbers lead, using large type and tabular figures

Nothing unrelated interrupts the active workout

07 — Design Process

The key design work was not adding screens. It was drawing clear boundaries between trust, speed, and interruption.

Explain why a weight is recommended

Problem: Showing only 32.5 kg × 10 × 3 gives no basis for trusting the recommendation.
My judgment: Trust comes from explaining the reasoning, not from making the algorithm look clever.
Design decision: The standard Player adds a plain-language reason such as ‘Last session completed → +2.5 kg.’
What I gave up: Focused mode removes the explanation. The reason belongs before commitment; execution keeps only weight, reps, and completion.

Turn insight from diagnosis into action

Problem: Telling someone that shoulder volume is low still leaves them to find an exercise and edit the routine.
My judgment: An insight that cannot lead to action is only half complete.
Design decision: The CTA carries the muscle-group context into filtered exercises, day selection, and a routine update in no more than three taps.
What I gave up: I deprioritised more charts so a smaller number of insights could change next week's behaviour directly.

Use rest time without taking control

Problem: RPE is useful to the progression engine but cannot interrupt training; a rest timer should not decide when the next set begins.
My judgment: Rest is the only low-cost question window, but responding must remain optional and ignorable.
Design decision: Rest mode provides three large RPE choices, count-up timing, and a subtle threshold cue. Reaching the suggested time changes the ring, copy, and one haptic only.
What I gave up: No countdown, automatic advance, or sound. I gave up stronger prompting to preserve the lifter's control.

Remove a seemingly finished lb switch before launch

Problem: The setting could save lb while the display remained fixed to kg. A control that appears to work but does not is worse than no feature.
My judgment: Launch scope must be judged by end-to-end behaviour, not by whether a setting exists.
Design decision: V1 hides unit switching until English localisation, real conversion, and progression increments are implemented together.
What I gave up: I gave up first-release flexibility for consistent, predictable behaviour in the initial market.

08 — Solution

The core path connects routine creation, in-workout logging, rest, and review into one continuous ‘next step’ loop.

Today | show only what matters now

A stateful hero card distinguishes ready, active, completed, and rest-day states. One Big Card makes starting the workout the single visual priority.

[Image: shot-1-today.png — interface evidence for this design decision]

Reppro Today screen with a lime Full Body A card and a prominent start button

Standard Player | understand, then act

Weight, reps, and sets lead the hierarchy. One sentence below the recommendation explains why, so the user can accept or adjust it before entering focused mode.

[Image: shot-4-player.png — interface evidence for this design decision]

Reppro standard workout Player showing a squat recommendation, its reason, weight, and rep controls

Focused mode | one job per set

Navigation and explanation disappear during the set, leaving exercise, weight, reps, and the completion CTA. Large figures and a lime next action support one-handed, sweaty use.

[Image: shot-2-focus-active.png — interface evidence for this design decision]

Reppro focused mode showing a 40-kilogram squat target with large numbers

Rest | show state without controlling pace

The timer ring, optional RPE, next-set summary, and start CTA coexist. Lime remains reserved for the true next action, while a cool green breathing cue distinguishes rest.

[Image: shot-3-focus-rest.png — interface evidence for this design decision]

Reppro rest state showing a timer ring, optional RPE choices, and next-set information

Session summary | close with restraint

Exercise count, sets, total volume, and new records establish accomplishment before the set-by-set history. There is no full-screen celebration after every set.

[Image: shot-6-summary.png — interface evidence for this design decision]

Reppro session summary showing total volume, new records, and completed sets by exercise

Progress | turn history into the next action

Weekly overview and muscle balance are not endpoints. Each insight includes an action that can update the routine directly.

[Image: shot-5-progress.png — interface evidence for this design decision]

Reppro Progress screen showing muscle balance and an action card for adding a chest exercise

09 — Impact & Validation

The evidence currently shows that the design and logic are systematically testable—not that market fit or retention has been proven.

Validation completed

Run every changed state in the simulator, capture it, and compare it with acceptance criteria
Audit design tokens, empty states, and state consistency
Pass 11 independent ProgressionEngine assertions across increase, maintain, stall, deload, and no-history conditions
Continue device QA and pre-launch refinement; public-market outcomes are not claimed

What to measure after launch

During QA and pre-launch testing, I evaluate one-handed task completion, time to record a set, incorrect taps, and comprehension of recommendation reasons. Week-four retention only becomes meaningful after a public release and a defined valid sample.

V1 contains no behavioural analytics, supporting the privacy position that workout behaviour is not collected. The cost is losing the in-app funnel between onboarding, starting a workout, completing a log, and paying.

Hypotheses to test

People will pay for ‘tell me what to do next,’ but not for basic logging.
Recording a set within three taps will reduce the likelihood of abandoning logs mid-workout.
A plain-language reason will build more trust than a recommended weight alone.

10 — Reflection

The strongest result came from removing interruptions with one consistent set of principles. The largest unknown is whether recommendations are worth paying for.

What worked

One Big Card, semantic two-colour use, and the principle that active training is protected time made it easier to judge whether new requests belonged on screen. Screenshot audits exposed inconsistencies between states more reliably than component specifications alone.

What I would change

Discovery still relies heavily on my own training context. I would move real-device testing beside equipment earlier instead of relying on the simulator—especially for sweaty hands, one-handed touch, Dynamic Type, VoiceOver, haptics, and lock-screen notifications.

Next step and unresolved question

The unresolved question is whether the recommendation engine should include RPE. Rep-based double progression is easiest to explain, but it may still recommend an increase after a very high-RPE session. I would first make RPE capture frictionless, then compare a rep-only rule with a ‘maintain when RPE is high’ rule before introducing a more complex model.

Next projectReturn to work index