Should I vibe code
Log workouts, templates, sets, rest timers, and personal history locally
Logging sets is a table. Importing Apple Health turns your weekend project into a medical file with your name on it.
?
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
The third lifting logger on this site and still a yes, because the arithmetic has not changed: one user, one database, no money, no strangers, and a worst case where you delete a repo. Where Strong differs from Hevy and Fitbod is the two features people actually pay for, and both are instructive. The first is the watch — logging a set from your wrist while the bar is still loaded, which a web agent cannot build for you and which is the difference between a tracker you use and a tracker you screenshot. The second is Apple Health, and that is the one line in this entry worth slowing down for: sets and reps are a notebook, but the moment you pull weight, resting heart rate and sleep across from Health to draw a nicer chart, your weekend project is holding a small medical file. Build the logger. Think twice before you widen the import.
What actually breaks
not "if". the specific failures.
- The wrist gap, which is the whole reason Strong Pro costs money: your version lives on a phone you have to unlock, on a bench, with chalk on your hands
- The Apple Health import, which arrives as body weight, resting heart rate and sleep alongside the sets, and quietly turns a lifting log into a health record that is now synced to whichever cloud you chose without thinking
- Body measurements and the muscle heat map, which need a muscle-group mapping for every exercise — a tedious taxonomy nobody finishes, so half the map stays grey forever
- The warm-up and plate calculator, because the answer depends on which plates your gym owns and you will hardcode a set that is wrong the first time you travel
- RPE, which is only useful if it is entered every set and is the first field you stop filling in
- Importing your existing Strong CSV, whose column layout has changed across versions, so a parser written against the file you exported today silently mangles the one you exported in 2019
- The rest timer, when the screen locks, the app is backgrounded and the notification never fires
Is that you?
the verdict is a default, not a law
- The only body in the database is yours
- The log works offline, in a basement, with one thumb, before it works anywhere else
- You want to track something Strong does not — bar velocity, per-side loading, autoregulated jumps, whatever your programme actually runs on
- There is an export you did not have to remember to run
- You are logging clients' training as a coach, which is other people's body data and a different entry entirely
- You are importing Apple Health and then syncing that database somewhere you have not thought about
- The only copy of eleven years of training lives in one browser's local storage
- You are adding a feed, followers and workout sharing, which is a community and inherits a community's problems
If you build it anyway
the checklist, then the prompt that enforces it
- Decide before you start whether Apple Health data comes in at all. If it does, keep it in a separate store from the sets, never send it to a third-party API, and write down what happens to it when you stop using the app.
- Build the CSV export before the first chart, and make the app import its own export. That round trip is the whole exit plan.
- Give every exercise a stable id and one canonical name on day one. Free-text names are the one mistake here you cannot fix later without guessing.
- Store the weight exactly as entered with its unit and convert only for display, or a personal best will gain a decimal on a round trip.
- Treat offline as the default state, not the error state. Writes go to local storage and sync afterwards.
- Back up before every schema migration — supersets, drop sets and per-side loading are the three changes of mind that eat history.
- Do not put an authentication system in front of it until there is a second user. There is no second user.
I am building a personal lifting log for myself — exercises, sets, reps, weight,
RPE, rest timers and progress charts. One user, no accounts, no social feed.
Follow this order and push back when I try to jump to the charts.
1. Ask me up front whether this will ever read Apple Health or Google Fit. If I
say yes, tell me plainly that body weight, resting heart rate and sleep are a
different category of data than sets and reps, and keep them in a separate
store with their own deletion path.
2. Never send health or body-measurement fields to any third-party API, including
an LLM, without asking me first in that specific moment.
3. Show me the data model before any UI: stable exercise ids that are never free
text, sessions, sets, and a unit on every weight. Tell me what happens when I
rename an exercise in year three.
4. Store weights exactly as entered and convert only for display. Add a test that
writes 100 kg, renders in lb, re-reads, and asserts the stored value is still
exactly 100 kg.
5. Build the CSV and JSON export next, plus an importer that reads its own
export, and prove the round trip on an empty install.
6. Then persistence, local-first. If the client is a browser, tell me exactly how
this survives a cleared cache, and put a copy somewhere durable on a schedule
I do not have to remember.
7. Then logging. It must work with no signal, one thumb, and two seconds of
attention between sets. Optimise taps, not appearance.
8. Then a rest timer that still fires when the screen is locked.
9. Only then charts. Name the one-rep-max formula on screen and keep it fixed; if
I ask to change it, warn me that the entire history moves with it.
10. Every schema migration takes a backup first and is reversible. Say so in the
migration file.
11. Out of scope on purpose: coaching other people, a social feed, sharing images
of my workouts. If I ask for coaching features, tell me that logging somebody
else's training is a different project with somebody else's body in it.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
Almost always, if the log has to be on your wrist. $4.99 a month, $29.99 a year, or $99.99 once buys a native iPhone app, an Apple Watch app, Health integration somebody else has already argued with, a maintained exercise library and an export that has kept working for a decade. Build your own because you want a metric nobody supports, or because building it is the fun part — not to save five dollars.
$4.99/mo is cheaper than your weekend.
One CSV of sessions and sets with exercise names resolved rather than left as ids, written somewhere durable on a weekly schedule. Strong's own export is that shape, every other tracker imports something close to it, and a spreadsheet reads it directly — so the day you lose interest in maintaining the app, you lose the app and keep the decade.
Active open-source fitness and workout manager, and a free exercise database you can borrow instead of typing one.
Open-source lifting tracker with a scripting language for programmes, aimed at people who would otherwise write their own.
Questions
Three workout trackers on this site, three SHIP ITs. Is that not a bit soft?
It is the same honest answer to the same shape of problem. One person, one device, no money, no strangers, nothing a regulator has written about, and a failure mode that costs you your own history. That is what SHIP IT is for. The differences show up in the prose rather than the verdict: Hevy's is backups, Fitbod's is the moment the app starts telling somebody else how much to lift, and Strong's is the wrist and the Health import.
Why does Apple Health change anything if it is still just my data?
Because of what it is and where it ends up. Sets and reps are a notebook. Resting heart rate, weight trend and sleep are the sort of thing an insurer, an employer or a data broker would find interesting, and a hobby app tends to sync everything to the same cloud bucket with the same casual permissions. Keeping the Health import in its own store with its own deletion path costs an hour and means the answer to "what have I actually got in here?" stays short.
Can I get my history out of Strong first?
Yes, and do it before you start building — Strong exports CSV, and having a real file of your own training makes the schema decisions concrete instead of theoretical. Write the importer against your actual export, not against an idealised one, and keep the original file.
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.
Four columns and a timer. The only way this hurts is losing four years of them to a cleared cache.
A workout app is a table of sets and a plus-2.5kg rule. The exercise science was never the software.
Your scale lies by two kilos and your food log lies low. Yours will not be smart. It will just be confident.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice