Should I vibe code
Record user-chosen nutrition information and show neutral trends without aggressive targets
Your scale lies by two kilos and your food log lies low. Yours will not be smart. It will just be confident.
?
Their verdict, the MacroFactor monthly subscription 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 logging half is the same CRUD app as every other tracker, and the nutrient numbers are free from USDA FoodData Central. MacroFactor’s actual product is the estimator: it reads your weight trend against what you logged, infers what you are really burning, and moves your targets every week. That is a filtering problem over two badly behaved signals — a scale that swings two kilos on salt and sleep, and food logs that are under-reported by almost everybody who is genuinely trying — and an agent will cheerfully produce something that looks exactly like it and behaves nothing like it. A tracker that is wrong is annoying. An estimator that is wrong tells a person to eat less, in a confident typeface, every Monday morning.
What actually breaks
not "if". the specific failures.
- The expenditure estimate after a week that breaks the model — a holiday, a stomach bug, three days of not logging. Garbage in, and the output is not an exception, it is a new and lower calorie target
- Under-reporting, which is universal and one-directional. If the log runs fifteen percent light, the estimator concludes you burn less than you do and prescribes accordingly, every week, compounding
- Weight noise. Without a proper trend filter a salty dinner on Sunday moves Monday’s targets, and the app looks responsive right up until you notice it is chasing water
- The food database: portion units, branded products, and barcode lookup with no free, complete and legally clean source — the same curation problem the Cronometer entry describes
- Targets rendered in the same authoritative type as everything else, when they came from a filter you and an agent wrote on a Sunday and never validated against anything
- The friend who asks for a login, at which point you are storing another identified person’s weight, body composition and eating history
Is that you?
the verdict is a default, not a law
- It is yours alone, and you treat every number it produces as a suggestion you sanity-check against how you actually feel
- It logs and charts, and leaves the prescribing to you or to a professional
- The data stays on your device and exports to CSV whenever you ask
- Anyone else uses it, and especially anyone with any history of disordered eating
- The app can lower a target without showing you the inputs that caused it
- There is no floor below which a recommended intake can never go
- You would hold weight, body-fat or intake data for a person who is not you
If you build it anyway
the checklist, then the prompt that enforces it
- Floors before features. Hard-code a minimum intake the algorithm may never recommend below, and refuse to render a number under it at all.
- Show the working on every adjustment: trend weight, logged intake, the window used, and the resulting estimate. A target with no explanation is the failure mode of this whole category.
- Cap how far a target may move week to week, so one bad fortnight cannot walk the recommendation down a cliff.
- Detect incomplete logging and skip the update rather than modelling around it. Say "not enough data this week" out loud.
- Never react to a single weigh-in. Use an exponentially weighted trend and show the raw points beside it.
- Treat this as health data: encrypted at rest, no analytics SDKs, and an export-and-delete path built before the login screen.
- Put a plain disclaimer in front of it and keep every string non-clinical. Nothing in the app should read as medical advice, because it is not.
I am building an adaptive nutrition tracker that estimates my energy expenditure from weight trend and intake, then sets targets. The estimator is the dangerous part.
1. Before any estimator code, hard-code an absolute minimum daily intake and
refuse to display or recommend anything below it, whatever the maths says.
Make that floor visible in the UI.
2. Cap the week-over-week change in any target to a small percentage, and
never let two consecutive weeks both reduce it without my confirmation.
3. Every target change shows its inputs: trend weight, average logged intake,
the date window, and the resulting expenditure estimate. No number may
appear without the reason beside it.
4. Use an exponentially weighted trend for body weight, never a single
measurement, and plot the raw points alongside the trend.
5. Detect incomplete or missing logging and skip the weekly update, saying so
explicitly. Do not impute, interpolate or "estimate around" gaps.
6. State in the README that logged intake is systematically under-reported,
and that an estimator fed a light log will prescribe a deficit that is
deeper than intended. This is the failure I am most trying to avoid.
7. Store food entries as a source identifier plus grams, not resolved
nutrient values, so the log still means something when the database is
revised. Use USDA FoodData Central or Open Food Facts; do not scrape a
commercial nutrition database.
8. Build CSV export of weight, intake and targets before the tracking UI, and
a complete delete that removes derived history too.
9. Keep it single-user and on-device. If I ask to add accounts for other
people, stop and tell me I am now holding somebody else’s health data.
10. No clinical language anywhere, and no diagnosis, no eating-disorder
screening, no medical claims. Add a plain disclaimer on first run.
11. Out of scope, and say so instead of faking it: barcode scanning against a
licensed database, photo-based logging, and coaching content.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
You want the algorithm rather than the app. Twelve dollars a month, or $71.99 for the year, buys an expenditure model that has been run against a very large number of real people’s bad weeks — which is exactly the validation your version will never have. If the goal is simply logging what you eat, Cronometer’s free tier already covers it against a curated database, and the Cronometer entry makes that case in more detail.
$11.99/mo is cheaper than your weekend.
Two CSVs are the whole asset: daily weight and daily intake, dated, with food entries stored as source id plus grams. Any tracker will import them, and the estimator can be re-run from scratch at any point because it derives everything from those two series. What you must not do is let the targets be the only record — a table of prescriptions with no inputs behind it is unportable and, worse, unauditable.
Self-hosted open-source fitness, nutrition and body-weight tracker with an existing data model to borrow.
Open, freely licensed product and barcode database — the only clean answer to the scanning problem.
Questions
How is this different from the Cronometer entry?
Cronometer’s product is curation — one checked entry per food instead of forty user-submitted versions of chicken breast. MacroFactor’s is inference: it produces a recommendation from noisy data and updates it weekly. Getting a food database slightly wrong makes a day inaccurate. Getting an estimator wrong makes a month of prescriptions wrong in the same direction.
Is the adaptive TDEE maths actually hard?
The energy-balance arithmetic is trivial. Making it stable is not. You are separating a real signal of a few hundred calories from daily weight noise of a kilo or more and intake logs with a systematic bias, which is a filtering and outlier-handling problem, and the symptom of getting it wrong is a plausible number rather than an error.
Why is regulatory exposure a 5 for a personal tracker?
Body weight, body composition and eating behaviour are special-category data under GDPR Article 9 the moment anyone else is in the app, and in the US, health apps outside HIPAA still sit under the FTC Health Breach Notification Rule. A wellness tracker that gives no diagnosis stays outside device regulation, which is exactly why the wording of what it claims matters.
- GDPR Art. 9 — processing of special categories of personal data (EU)
- FTC Health Breach Notification Rule (US) — covers health apps outside HIPAA
- FDA — General Wellness: Policy for Low Risk Devices (US)
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.
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.
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