GymTracker sits on tools.danieldiaz.dev. It is not a gym app. It is a small habit system. If you treat it like a consumer fitness product, you will build the wrong thing and ship theater.

The mistake: treating habit as a feature list

When I started, the temptation was familiar: workouts library, charts, social, AI coaching, streaks that look good in a screenshot. That list feels like progress. It is usually a drawer full of unfinished surfaces. A habit system has a narrower job: make the next honest action obvious, cheap to record, and hard to fake. Everything else is optional until that loop survives a bad Tuesday.

The minimum state that matters

I only need a few facts to keep the loop honest:

• When was the last session?
• What is the next concrete action?
• Did I show up this week, or am I negotiating with myself?

If the UI cannot answer those in a glance, the system is already failing. Fancy history that nobody opens does not count as state. State is what changes the next decision.

Deliberate friction vs accidental friction

Some friction is useful. Asking for a short confirmation before you mark a session done slows vanity logging. Accidental friction is different: another login, another blank form, another "I'll do it later" screen. Rule I use: if recording a session takes more than about sixty seconds of honest input, the system failed. Not my willpower. The system. That number is falsifiable. If I keep missing days because capture is annoying, I cut fields before I add motivation features.

Feedback that is not a vanity metric

A green chart is not feedback. Feedback is: did you return, how long did capture take, and did the next action stay clear after a messy week? I care more about return rate after a miss than about volume records. Missing a day is normal. Losing the thread of what to do next is the real break.

What I refused to build on purpose

No social feed. No coaching chatbot. No dashboard that exists to impress someone who does not train with me. Those features pull the product toward ECORPA-scale promises with none of the operational contract. GymTracker can stay small because its user is me. ECORPA cannot stay small in the same way: when it fails, someone else's hiring timeline fails. Same craft — reduce rework, respect judgment — different promise. That is why tools live apart from the company, as I wrote in why tools lives apart from ECORPA.

Same craft, different contract

If you are building a personal system, borrow the discipline, not the org chart. Define the loop. Cut accidental friction. Keep one falsifiable kill rule. Ship the boring reliable piece. Then leave the rest in the drawer until the loop is real. The 99% that stays in the drawer is not failure. Shipping a habit app costume before you have a habit system is.