Personal need
Build the tool I would keep using.
Fast shorthand logging and video review came first. The product began inside my own training routine.
Independent product · iOS · Live
I built Chalky to make a workout log useful after the workout.
Chalky turns what an athlete actually did into a clear next decision, while keeping the log fast and every recommendation inspectable, editable, and optional.
- Role
- Independent product designer and engineer
- Scope
- Research, UI, iOS, backend, launch
- Evidence
- Live product, 60+ beta testers
App Storelive product
60+pre-launch testers
iPhone + Watchone workout record
Independentproduct through support
From side project to product
Chalky started as a tool I needed.
I was not trying to start with a platform. I wanted a quicker way to log my own training and a practical way to review my form from video. I built both for myself, used them between sessions, and kept finding the same missing handoff: the record was useful, but it still left the next decision to me.
That repeated use changed the scope. Logging and Form Check were not isolated features. Together, they could help answer what happened, what mattered, and what to do next. That was when I decided to turn Chalky into a product.
Product evidence
Study where the value repeated.
Continued use exposed the real job: connect recorded work to a trustworthy next action without adding gym admin.
UX research
Test the problem beyond myself.
I mapped user jobs, audited competing flows, analyzed logging friction and trust failures, and tested early language and interactions with people who train.
0→1 rebuild
Rework the product around one loop.
I rebuilt the information architecture, core flows, state model, visual system, and recovery paths before taking the new product through TestFlight and launch.
01 · The problem
Workout logs remember. They rarely help.
I had months of useful training data in Notes: shorthand, loads, reps, energy, pain, and context. The information was there. The next decision was not.
Most strength products solve this by forcing every session into a rigid form. That creates clean data at the cost of attention. Logging becomes admin.
I saw a different opening: preserve the speed and flexibility of notes, then add structure only when it earns its place.
02 · User needs
Three jobs became the product brief.
When I finish a session, let me record it in my own shorthand without turning training into data entry.
When I look back, show me the pattern that matters instead of another dashboard I have to interpret.
When something should change, give me one specific next move and let me accept, edit, or reject it.
03 · Competitive analysis
The gap was not another set counter.
Strong centers fast logging. Hevy pairs logging with progress and social motivation. Fitbod centers adaptive programming. Chalky focuses on making the path from recorded work to the next decision visible and controllable.
| Product | Center of gravity | What I took from it |
|---|---|---|
| Strong ↗ | Fast, structured workout tracking | Logging speed is a feature. Coaching cannot slow it down. |
| Hevy ↗ | Logging, progress, and social motivation | History can motivate through a clear next action without requiring a social feed. |
| Fitbod ↗ | Generated, adaptive programming | Adaptation alone is not the difference. Its reason and override have to stay legible. |
| Chalky | Recorded work → inference → proposed change → athlete choice | Design the loop so the athlete can inspect each handoff and keep control. |
The product loop
Each action improves the next one.
- 01PlanSet intent
- 02LogCapture the work
- 03ReadFind the pattern
- 04AdaptUpdate the next move
04 · Product and UI
The interface makes the system legible.
Every screen below is the product: the same interface, hierarchy, and states people use in Chalky.
A · Capture
Natural notes first. Structure when it helps.
The Logbook is the center of the product. A day can begin as shorthand and become editable sets without erasing the original record.
- Signal Shorthand was fastest during a workout. Structured fields were easier to analyze later.
- Decision Notes and structured sets share one day record, and both remain editable.
- Tradeoff Parsing and reconciliation became harder than enforcing one input format.
B · Understand
Translate history into a useful read.
Stats is organized around training questions: balance, activity, recovery, and consistency. Low-signal periods do not pretend to be conclusions.
- Signal Raw tonnage makes naturally stronger muscle groups dominate a balance chart.
- Decision Use working sets for cross-muscle balance and tonnage for like-for-like change.
- Tradeoff The chart looks less dramatic, but the comparison means what it says.
C · Adapt
Recommendations arrive with evidence and an exit.
Chalky can build a plan, prepare today’s session, and propose changes from observed behavior. It never silently rewrites the athlete’s plan.
- Signal An automatic change can be useful and still feel like lost control.
- Decision Show the source, proposed change, and apply, edit, skip, or undo path.
- Tradeoff Adaptation needs more states than silently rewriting the plan.
D · Validate
One filmed set becomes one clear priority.
Form Check separates what worked, what needs attention, and what to try next. Scores sit beside the movement evidence instead of replacing it.
- Signal A score detached from the movement can look certain without being useful.
- Decision Keep the lift, criteria, confidence, and next cue in one hierarchy.
- Tradeoff Evidence gets the space that decoration and secondary detail would have used.
05 · Product decisions
The hard part was deciding what Chalky should refuse to do.
Input
Do not make clean data the athlete's job.
Freeform notes and structured sets coexist. Parsing can help, but the original entry stays visible and every result stays editable.
Cost: more reconciliation than a form-only logger.
Control
Never turn a suggestion into a silent change.
Plan and load changes arrive as proposals. The athlete can apply, edit, skip, or undo, and Chalky records that response.
Cost: more product states. Benefit: the plan remains theirs.
Reliability
Let the gym be offline.
A completed log writes locally first. Sync retries later inside account-scoped boundaries instead of blocking the workout.
Cost: conflict and deletion logic instead of a simpler online-only flow.
Trust
Reject weak intelligence.
Generated output passes typed validation and product rules before it reaches the interface. Low confidence and failures stay visible.
Cost: sometimes showing no answer instead of a polished guess.
06 · System design
Chalky is split where the failure modes change.
Logging, account state, sync, subscriptions, and generated coaching fail in different ways. Their boundaries make those failures easier to contain and recover from.
System active
One workout, resolved across the product.
Conceptual model. Select a node to inspect its responsibility.
Product signals
Product responses
Decision boundaryChalky's brain
Inputs become stable product state through typed contracts, validation, and deterministic rules.
Prompts, thresholds, schemas, and private coaching logic are intentionally omitted.
This is a product-level map, not an implementation diagram. It shows responsibility and trust boundaries without exposing private coaching logic.
Features own their behavior
Logbook, Coach, Stats, Form Check, onboarding, and subscriptions keep their views, models, and services together. Shared code stays limited to real cross-feature needs.
One writer per domain
Long-lived state changes pass through isolated writers. That gives sync, background work, and the interface one place to enforce ordering.
Automation has a boundary
Typed contracts, validation, deterministic rules, and explicit confirmation sit between generated output and user data.
Session changes drain first
Account-scoped work, caches, observers, and notifications shut down before the next identity becomes active.
The same boundary appears throughout the app: generated systems can extract and explain, while ordinary software owns identity, persistence, validation, and consequential state.
07 · Design system
A design system for quick glances and moving hands.
In the gym, attention is scarce. The interface keeps the next action obvious, data stable, and state changes easy to read.
Signal Mint
#38D1ADRubber Black
#121212Plate Charcoal
#2A2A2AQuiet Steel
#A6A6A6Mint is a signal.
It marks readiness, focus, completion, and the next primary action. It never becomes wallpaper.
Motion explains state.
Transitions show what changed. Reduced Motion communicates the same information without choreography.
Numbers stay still.
Monospaced digits, explicit units, and stable layouts keep live data readable under load.
08 · Launch and learning
The beta became a real product.
More than 60 people tested Chalky through TestFlight before launch. Their use exposed defaults that were too confident, labels that were unclear, and recovery paths that were missing. I used those sessions to tighten onboarding, logging language, and failure states.
Chalky is now live on the App Store with real users. The current user count stays private; the product does not.
60+TestFlight testers before public release
Liveshipping product with active users
One ownerresearch, product, design, engineering, support
09 · Reflection
What building the whole system taught me.
Freeform input was the right expensive choice.
It produced a better logging experience and a harder data problem. The extra parsing, validation, and editing work was worth keeping attention on the workout.
Generated systems improve when their job gets smaller.
Extraction and explanation can be probabilistic. Identity, persistence, adherence, and user-approved changes should not be.
One workout has to mean one record.
Cross-device sync changed the product model as well as the backend. iPhone and Apple Watch rebuild the same session instead of owning competing copies.
Live product
See Chalky in the wild.
The product is shipping, evolving, and used by real athletes.
Open Chalky↗