Best macro tracker for training: why databases fail
Standard calorie apps drop the timing, cooking state and safety data that training plans need to actually work.
Standard calorie apps drop the timing, cooking state and safety data that training plans need to actually work.
Most food-tracking apps carry a database that started as a spreadsheet and grew as users contributed entries. That works for the majority of users, who want to know roughly what they ate and what it added up to. It stops working the moment the user trains seriously, because people who train need information the spreadsheet never contained: cooking state, glycemic load per serving, digestion speed, protein type, meal-slot fit, sex-specific safety floors.
This piece walks through the ten specific things a crowd-sourced tracker database cannot tell someone who trains, and how KEXBI's food database was built to close each one. This is the fifth article in the fuel-database series. The first four unpacked one dimension each; this one packages the case.
The crowd-sourced tracker cohort share five architectural traits. First, entries are user-contributed, with a light moderation layer. Second, macros are stored on a single basis per entry, usually cooked, sometimes raw, occasionally as-purchased, and the entry does not flag which. Third, glycemic index is present in some entries and absent in most; glycemic load is never derived per serving. Fourth, no per-slot scoring exists; every food reads as the same fit at every time of day. Fifth, no safety layer sits above the numbers; the app records what the user enters and defers any hormone or metabolic risk assessment.
None of these are failures of the product. They are consistent with the market the product was built for: general-population weight tracking, where a rough macro total is enough. The failure comes when someone who trains uses the same tool for a job it was not designed for.
| Feature | Crowd-sourced cohort | KEXBI |
|---|---|---|
| Verified provenance (USDA-anchored, hand edits locked) | No | Yes |
| Raw and cooked macros with yield factor | No | Yes |
| Per-cooking-method transforms (9 methods) | No | Yes |
| Glycemic index on every carb food | Sparse | Yes |
| Glycemic load derived per serving | No | Yes |
| Gastric residence and protein type classification | No | Yes |
| Meal-slot fit scored across 11 windows | No | Yes |
| Amino-acid resolution (leucine, lysine, valine per 100 g) | No | Yes |
| Chrononutrient timing rules (time-of-day bias) | No | Yes |
| Sex- and body-fat-modulated safety floors (EA, fat, protein) | No | Yes |
The most common quiet error in tracking for training comes from mixing conventions. You weigh your food after cooking (that is where the scale usually sits) and the tracker returns numbers on a raw basis, or vice versa. For lean protein that under-counts by 25 to 35 percent. For dry grains that over-counts by a factor of the yield.
The crowd-sourced tracker cohort cannot solve this because their entries do not record whether the numbers are raw or cooked. KEXBI stores raw or dry as the master value, holds the yield factor and per-method overlays, and materialises the correct value at record time. The reader does not carry the maths. The engine does. Article 2 in this series unpacks the problem in full.
A generic tracker sees only the macro total. It does not know whether the carbs sit in the pre-workout window or the pre-bed window, and it does not treat the two differently. For a sedentary user, this is fine. For someone building meals around their training, the same carb total at a different time can do different work.
KEXBI's food database carries glycemic index on every carb food and derives glycemic load per serving at runtime. The meal plan applies chrononutrient rules that bias food choice by slot: high-GI carbs are bonused post-workout and penalised pre-bed, low-GI carbs are the opposite. Article 3 covers the timing case in full.
A generic tracker sees food and macro totals. It does not carry a per-slot fit score. So a meal plan built on the tracker's data cannot route foods to the right time of day; it can only sum them.
KEXBI's food database scores every food across 11 named meal windows: breakfast, snack, lunch, dinner, pre-bed, pre-workout at T minus 120, 60, and 30, intra-workout, post-workout immediate, post-workout meal. Each score is derived from digestion speed, GI, fat, fibre, and protein type. The meal plan uses the scores to pick foods for the specific slot in front of it, rather than treating all slots as identical. Article 4 covers the scoring in full.
Every field on a KEXBI food document carries a record of where its number came from. Macros read VERIFIED for calories and protein when the food has been hand-confirmed against USDA FoodData Central [1], the UK's CoFID [2] or Germany's BLS. Micronutrients read USDA when the source is USDA. Yield factor names USDA Agricultural Handbook 102 or a CoFID recipe as its source [3][7]. Nothing on the record is a user-contributed guess.
Above those source records sits a check by hand. A small number of foods have had their slot scores checked and edited by hand, and those edits are locked. Subsequent enrichment passes are permitted to fill sparse fields but cannot overwrite the locked ones. It covers a handful of foods, not the whole database, and it is designed to stop a correction made by hand being silently undone.
The last differentiator is where the moat becomes a safety question rather than a nutritional one. People training on a cut are one of the populations most exposed to relative energy deficiency in sport (RED-S) and low-fat-induced hormonal disruption. Research treats these risks as a continuum rather than one universal cut-off, and suggests they differ between women and men [4,5]. KEXBI therefore sets its floors by sex and scales them to your body.
A crowd-sourced tracker does not carry sex-specific EA floors or fat floors on any food document, because the database has no concept of the user's body composition. KEXBI's food database sits under a safety layer that does: energy availability is computed against the user's lean mass, the fat floor is scaled to their bodyweight, and protein is set per kg of their lean mass for their goal (cut, maintain, gain, performance). Both the database and the safety layer are needed for the check to work. The "Plan You Cannot Cook" audit walks through what happens when the check is absent.
Each of the ten differentiators is individually valuable. The reason the moat matters is that they compound. A meal plan built without raw-vs-cooked conversion undercounts protein. Without GI and GL, it routes the same carbs to the wrong window. Without slot fit, it puts chicken breast at 10 pm. Without sex-specific EA floors, it can silently let the person fall below a safe energy-availability floor on a cutting day. Each error is small; the day carries five of them; the week compounds; the month lands wrong.
The generic tracker's architecture invites all five errors simultaneously. The verified, per-slot, safety-audited food database is designed to catch them at the schema level. That is the moat: not one clever feature, but the compound effect of every difference visible in the schema.
In consumer nutrition, the food database is the product. Not the app UI, not the meal plans, not the graphs. The database is what every downstream decision runs on top of, and the ceiling of the app is set by the ceiling of what the database can carry.
The crowd-sourced tracker cohort built for the general-population weight-tracking market and ships databases suited to that market. KEXBI's food database was built for people who train, where the difference between a plan that reads well and a plan that works is exactly the ten differentiators above. That is not a marketing claim. It is a schema-level fact you can point at in any single food document.
The ten differentiators listed in Fig 1 are schema-level facts about KEXBI's food document format, cross-referenced against the field set common to the crowd-sourced tracker cohort. Specific competitor products are not named; the audit describes the architectural pattern shared across free consumer trackers. The safety floors described in Chapter 07 are computed by the KEXBI runtime against the user's lean mass and body composition; the food database carries the classification metadata that makes those checks possible.