Should I vibe code
Build moderate workout plans from user-selected equipment and recovery notes
A workout app is a table of sets and a plus-2.5kg rule. The exercise science was never the software.
?
Their verdict, the Monthly 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
Everything Fitbod does that matters to one lifter — remember last Tuesday's numbers, put them on screen at the right moment, add a little weight — is a table of sets and a rule. What you are not rebuilding is the fatigue model, and if you already know which programme you are running, that model is something you were overriding anyway. Nothing leaves your phone, nobody else reads it, and the worst outcome is losing your own history. Build it. Then notice that the verdict flips the day it starts telling somebody else how much to lift.
What actually breaks
not "if". the specific failures.
- The exercise library — the boring half nobody wants to build, and the half you touch every single session
- A progression rule that keeps stacking weight through a bad week, because your version has no idea you slept four hours
- Four years of training history in one unbacked-up SQLite file, on a phone you will eventually drop in a squat rack
- Sync, the day a second device appears and two offline clients edit the same session
- The moment you hand it to a friend and it starts prescribing loads to a body you have never met
Is that you?
the verdict is a default, not a law
- You are the only person who reads what it prints
- The data lives in a file you can open — SQLite or CSV — somewhere you control
- You already know your programme and what you want is a faster notebook, not a coach
- Other people are going to follow the numbers on the screen
- You are selling it, at which point strangers' bodyweight and measurements become data you hold
- What you actually wanted was the recovery model, because that is the part a rule cannot fake
If you build it anyway
the checklist, then the prompt that enforces it
- Export first. Every session, every set, to CSV, working before there is anything worth exporting — training history is the one thing here you cannot recreate.
- Back up on write, not on a schedule you will forget to check. Keep the last thirty copies.
- Bound the progression rule: show it in the UI, cap the jump, and never increase twice running without a completed session in between.
- Seed the exercise library from an open dataset rather than letting a model invent four hundred plausible-looking movements.
- Keep bodyweight, measurements and progress photos in the app container, out of anything that syncs to a shared drive.
- Offline first. Gyms have concrete walls, and a logger that needs a network is a logger you stop opening.
I am building a personal strength-training logger. Single user, my own device, and the real risk here is losing data rather than leaking it. Apply these constraints and push back if I ask you to break them. 1. Build export before logging. A command that writes every session, exercise, set, weight and rep to CSV, and that works against an empty database, before there is anything in it worth exporting. 2. Store everything in plain SQLite with a schema a human can read. No opaque blobs, no proprietary archive, nothing that needs this app to open it. 3. Keep a rolling backup on every write — timestamped copies, last thirty kept. The training history is the only irreplaceable thing in this project. 4. Offline first: the app must work fully with the network off. If I ask for sync later, tell me first that two offline clients editing one session is a merge problem, and design for that instead of last-write-wins. 5. Seed the exercise library from an open, attributable dataset. Do not generate exercises. Tell me where the data came from and what its licence is. 6. Any progression rule must be visible and bounded: show the rule in the UI, cap the increment, and never add weight two sessions running without a completed session between them. 7. Do not present output as medical or coaching advice. No rehab programming, no injury guidance, no calorie or macro prescriptions. 8. Keep bodyweight, measurements and photos inside the app container, out of synced folders, and out of every log line. 9. If I ask to add other users, stop and tell me this stops being a notebook and becomes an app that prescribes loads to bodies neither of us has seen — and that accounts, consent and deletion all arrive on the same day. 10. Say plainly in the README that this is a log, not a coach.
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
$15.99 a month buys the fatigue model, a filmed exercise library and someone else absorbing every iOS release. If you do not already know what programme you are running, that guidance is the entire product and no amount of logging will supply it.
There is barely an exit to plan, which is the point. If the set history exports to CSV and imports into Hevy or a spreadsheet in one command, abandoning the project costs you a UI and nothing else. Keep that export working in the months you are not touching the code, because it is the only part that outlives the app.
Active open-source fitness and workout manager, and the easiest place to borrow an exercise database rather than inventing one.
Questions
Fitbod's whole pitch is the algorithm. Doesn't building it without one miss the point?
If you are new to lifting, yes — the recommendation is the product and you should pay for it. If you already run 5/3/1 or a push-pull-legs split, the algorithm is the thing you keep overriding, and what you actually want is a logger that surfaces last week's numbers in one tap.
Why is this SHIP IT when so much of the list isn't?
Because nothing leaves the device. One user, no strangers' data, no money, no regulator, nobody else's uptime. The only failure that can genuinely hurt is losing your own history, which is why the export is the first thing to build rather than the last.
What changes if I put it on the App Store?
Every number in the risk table. Strangers' body metrics become data you hold, a suggested weight becomes advice you gave, and accounts, deletion and support all arrive together. That is a different entry with a different verdict — this one is about the version only you use.
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.
Four columns and a timer. The only way this hurts is losing four years of them to a cleared cache.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice