Nutrition tracking that starts with a barcode scan

Barcode scanning, with your phone camera

Packaged food already carries its own identifier. Scanning the barcode with your phone camera turns that identifier into a product entry: a name, a brand, a serving size and a nutrition table, without you typing any of it.

The scan is the fast path, not the only one. Some packages are not in any database, some are regional, and some carry a code that resolves to a different size of the same product. Every one of those cases falls back to the same place: a product form you can fill in yourself, which is the last section on this page.

Search by name, brand or barcode

Scanning works when the package is in front of you. The rest of the time you are adding something from memory — last night’s rice, the yogurt you always buy — and the way in is a search field.

The same search accepts a typed barcode number, which matters more than it sounds: a photographed label, a receipt, or an online grocery order all give you the digits without giving you the package.

• Search by product name.
• Search by brand, for the packaged version you actually buy.
• Search by barcode digits, typed rather than scanned.
• Save the result once — it stays in your catalog.

Where the nutrition data comes from

Pantensa looks products up in open food databases: Open Food Facts, which is where most packaged goods live, and USDA FoodData Central, which is where generic foods live — rolled oats, chicken breast, lentils, the ingredients a recipe is actually made of.

These two answer different questions. A barcode resolves against a packaged product; an ingredient in a recipe usually does not have a barcode at all, and is better served by a reference entry for the food itself. Both end up in the same catalog, and once they are in it, nothing looks anything up again.

Review and edit, before it becomes a number

Imported nutrition data is not automatically right. Open databases are crowd-maintained, manufacturers reformulate without changing the barcode, and the serving size printed on a package is frequently not the serving size anyone eats.

So the import is a draft. The values arrive filled in, you confirm them, and anything you change is what gets saved. If you weighed the portion yourself, your number wins over the label’s. If a field is genuinely unknown, leaving it empty means unknown — not zero, which would quietly understate every day it appears in.

This is the difference between fast setup and blind setup. The scan removes the typing; the review keeps the responsibility with the person who will be reading the totals later. The longer version of that argument — what the two databases actually disagree about, and why a confirmed number is worth more than a fetched one — is on the blog: why imported nutrition data is shown as a draft, not a fact.

One product, then recipes and meal plans

A product entered once is available everywhere after that. It goes into recipes as an ingredient, into the week plan as part of a planned meal, and into a day as something you ate — from one entry, not three.

That is what makes the catalog worth building rather than a chore to endure. The tenth time you log the same yogurt, there is nothing to look up, nothing to verify, and no chance that this week’s entry disagrees with last week’s.

The same products, later, in Pantry mode

Not in the first release

Pantry mode is not in the first release. When it arrives, it will use the catalog you already have: a product that carries a barcode and verified nutrition data is also a product that can carry a quantity, a batch and an expiration date.

Nothing about scanning changes then. The same scan that adds a product today will be able to add a purchase later, which is why building the catalog now is not work you will redo.