Data Engineering + Pipeline Architecture
An early-stage nutrition app needed the database behind their product: multilingual, validated, traceable to real sources, and structured so they could refresh it themselves. Not a scraped spreadsheet. A maintainable build.
A calorie-tracking app is only as good as the data underneath it. If a user searches "chicken" and gets four near-identical entries with different numbers, the product feels broken. If a restaurant item shows the wrong country's nutrition figures, it is worse than broken.
The requirement was a single canonical database covering generic ingredients, prepared dishes across world cuisines, restaurant chain menus, alcohol, supplements, and barcoded packaged products, in English, French, Spanish and Portuguese, with every value traceable to a real published source. No estimates. No filling gaps with plausible-looking numbers.
There was also a licensing constraint. Open Food Facts is published under ODbL, which carries a share-alike clause. Merged carelessly into the same database as proprietary data, it can force the whole thing open.
The hard problem in nutrition data is not collecting it. It is knowing when what you collected is wrong.
Every record was checked against the energy equation: calories should approximate four times protein, plus four times carbohydrates, plus nine times fat. A column that shifts by one during extraction produces numbers that look completely reasonable in isolation and fail that check instantly. It caught a taco reading as 3.5 calories and bacon reading as 12.
Coherence alone is not enough, though. It validates arithmetic, not reality. One parse produced a small coffee with more calories than the large — internally consistent, obviously wrong. Another market's data turned out to be a byte-identical copy of a neighbouring country's, English item names and all. A chain listed as operating in Australia turned out to be an entirely unrelated company that happened to share the name.
None of those are caught by a formula. They are caught by checking whether the data describes the world it claims to describe, and by refusing to load anything that cannot be verified. Calories-only sources were rejected rather than padded with estimated macros. Roughly 176 brand-market combinations were searched, documented, and recorded as genuinely unpublished rather than quietly filled in.
A delivered database of 46,000+ officially sourced restaurant items, 6,400 canonical ingredients drawn from USDA, CIQUAL, Japan MEXT, CoFID and BEDCA, 1,842 multilingual prepared dishes, 24,000+ portion records, and a separately licensed 2.4M-product barcode store — handed over with schema documentation, a refresh runbook, and a validation suite the client can run themselves.
The part I am most pleased with is not the row count. It is that every number in it can be traced back to who published it and when, and that the records which could not be verified are documented as gaps rather than disguised as data.