Should I vibe code
Log workouts and routines locally with neutral progress charts
Four columns and a timer. The only way this hurts is losing four years of them to a cleared cache.
?
Their verdict, the Pro price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
Exercise, sets, reps, weight, timestamp. The schema fits in a tweet and the app fits in an evening, and because the only person in the database is you, the worst outcome available is a repo you delete. Build it. Two things are worth knowing before you start. The first is that homemade trackers die in week three, not from bugs but from friction — logging a set on a web page between rounds is slower than a paper notebook, and Hevy's actual product is a native app that opens instantly, works with no signal in a basement gym, and takes one thumb. The second is that the value of the data is entirely cumulative: nothing is at stake in month one and four years of PRs are at stake in month forty-eight, so decide where they live and how they get out before the number gets big.
What actually breaks
not "if". the specific failures.
- The habit, around week three, when opening a web app mid-set turns out to be worse than the notes app you were already using
- Backups, which is the only genuine loss here: a browser-storage app plus a cleared cache is four years of training gone, with nobody to email about it
- The exercise list, which sounds trivial until you have three spellings of "Romanian deadlift" and your progress chart splits into three flat lines
- Unit handling — kilos entered, pounds displayed, conversion applied twice, and a personal best that is silently 2.2x wrong
- Whichever one-rep-max formula the agent picked without telling you, because Epley and Brzycki disagree and your chart will inherit the difference forever
- Offline behaviour in a basement with no signal, which is where the app is used and the one place a naive fetch-on-load design simply shows a spinner
Is that you?
the verdict is a default, not a law
- The only person in the database is you
- You build for the phone first, offline first, with the log writing to local storage that syncs later rather than the other way round
- You want metrics Hevy does not track — RPE, bar velocity, per-side loading, whatever your programme actually runs on
- An export lands somewhere you can see it, on a schedule you did not have to remember
- You are logging other people's training as a coach, because a client's body data is somebody else's information and a different entry entirely
- The only copy lives in one browser's local storage on one device
- You are adding a social feed and comments, at which point you have started a community and inherited its problems
- You are planning to import Apple Health or Google Fit and re-share what comes back
If you build it anyway
the checklist, then the prompt that enforces it
- Design offline-first. The log writes locally and syncs when it can; anything that needs the network to record a set will be abandoned in a fortnight.
- Store the weight exactly as entered, with its unit, and convert only for display. Round-tripping kg to lb and back is how a personal best gains a decimal.
- Give exercises stable ids and a canonical name from day one. Free-text exercise names are the one schema mistake here that cannot be fixed retrospectively without guessing.
- Automate the export: CSV or JSON to a folder that gets backed up, weekly, without you deciding to. The data is worthless in month one and irreplaceable in year four.
- Write the export and restore path before the charts, and test the restore at least once on a machine that has never seen the app.
- Pick a one-rep-max formula, name it in the UI, and never change it silently — a chart that shifts because you swapped estimators is a chart you stop trusting.
- Back up before every schema migration. You will change your mind about supersets, and that migration is the one that eats history.
I am building a personal workout logger for my own use — exercises, sets, reps, weight, notes, and progress charts. Single user, no accounts, no social feed. Build it in this order and push back if I try to skip ahead to the charts. 1. Decide the data model first and show it to me: exercise ids that are stable and never free text, sessions, sets, and a units field on every weight. Explain what happens when I rename an exercise in year two. 2. Store weights exactly as entered with the unit alongside. Convert only at display time, never on write. Add a test that enters 100 kg, displays in lb, re-reads and asserts the stored value is still exactly 100 kg. 3. Build the export before the UI: every session as CSV and JSON, plus an importer that reads its own export. Prove the round trip on an empty install. 4. Then persistence. Local-first storage, and if the browser is the client, tell me plainly how the data survives a cleared cache — and make a copy land somewhere durable on a schedule I do not have to remember. 5. Then logging. It has to work with no network, one thumb, and a screen I am looking at for two seconds between sets. Optimise taps, not appearance. 6. Then a rest timer that survives the screen locking. 7. Only then charts. Name the one-rep-max formula on screen and keep it fixed; if I ask to change it, warn me the whole history moves. 8. Any schema migration takes a backup first and is reversible. Say so in the migration file. 9. Out of scope on purpose: sharing, feeds, coaching other people, importing from Apple Health. If I ask for coaching features, tell me that logging somebody else's training is a different project with somebody else's data in it, and that Hevy costs about three dollars a month.
That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
Roughly always, if you want it on your phone. Hevy Pro is $2.99 a month, or $23.99 a year, or $74.99 once — cheaper than the coffee you have after the session — and it buys a native app, a watch app, a maintained exercise library and a backup you did not have to think about. Build your own for the pleasure of it, or because you track something nobody supports. Not to save the three dollars.
$2.99/mo is cheaper than your weekend.
CSV of sessions and sets, with exercise names resolved rather than left as ids, dropped somewhere durable on a weekly schedule. That is the whole plan and it takes an hour to build. Every other tracker imports something close to that shape, and a spreadsheet reads it directly — which means the day you get bored of maintaining your own app, you lose the app and keep the four years.
Active open-source fitness and workout management application.
Open-source weightlifting tracker with a scripting language for programmes, aimed squarely at people who would otherwise build their own.
Questions
Is workout data health data in the regulatory sense?
Your own sets and reps, kept for yourself, are not — this is a notebook, and no regulator has written anything down about your notebook. It changes if you hold other people's training and body measurements, particularly as a coach or a trainer with clients, because that is somebody else's data about their body and it is now sitting on your server.
What is actually hard about this build?
Not the logging. The exercise library, which needs names, aliases and muscle groups that stay consistent for years; offline behaviour, which is the difference between an app you use and one you look at; and backups, which are the only thing here you cannot fix after the fact. wger publishes an exercise database you can borrow rather than typing.
Should I add a social feed like Hevy has?
That is the moment this stops being a personal tool. Followers, comments and profiles mean moderation, private-by-default decisions and other people's data on your server, and it moves you into the same territory as the community entries on this site. Keep the log yours.
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
Your scale lies by two kilos and your food log lies low. Yours will not be smart. It will just be confident.
Nutrient data is free. A database where 'chicken breast' means exactly one thing is the entire product.
A workout app is a table of sets and a plus-2.5kg rule. The exercise science was never the software.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice