Nobody weighs a roti

Open almost any food logging app, search for rice, and look at what it wants from you.

It wants grams. It will offer a serving size, usually 100 g, and it will expect you to either accept that number or replace it with a better one. To replace it with a better one you need a kitchen scale, and to use a kitchen scale you need to be standing in your own kitchen, with the food in front of you, before you eat it.

That is a fine description of maybe one meal in four. The rest happen at a canteen counter, at somebody's dining table, in a car, at a wedding, at eleven at night when you get in from work. In none of those situations is there a scale, and in most of them there should not be one.

So people guess. And because guessing in grams is genuinely hard, people guess badly, feel bad about guessing badly, and stop logging. The churn does not come from the app being ugly. It comes from the app asking a question that most of the day cannot answer.

The unit people actually use

Ask somebody what they had for lunch and nobody says 180 grams of rice. They say two rotis and a katori of dal. They say a slice of toast. They say a cup of oats, half an avocado, a boiled egg, a handful of almonds.

These are household units, and they have two properties that make them worth building around. They are the unit the person already has in their head, so recall costs nothing. And they are surprisingly stable: a roti made by one household is not the same as another household's, but the spread is much narrower than the spread of a person's freehand gram estimate.

So in our catalog, grams are the storage unit and never the input unit. Every food carries a set of unit rows, and each row is a named portion with a gram weight and a list of the locales that actually use that word.

Look at the two rows for white bread. Same food, same catalog, two different gram weights, because a slice of bread in Britain is genuinely bigger than a slice in the United States and pretending otherwise puts a systematic error into every breakfast a British user logs. The locale tag is not decoration. It decides which units a given person is even offered.

Why the locale tag is on the unit, not the food

This is the design decision that took the longest to get right, and the one that most food schemas get wrong.

The obvious approach is to tag the food. Roti is an Indian food, so mark it Indian, and show Indian foods to Indian users. It works until the first person breaks it, which takes about a day. Someone in Chicago eats rotis. Someone in Mumbai eats oats with a measuring cup because that is how the packet is written. A Gujarati household in Toronto wants katoris and cups in the same meal.

Tagging the food means those people get a catalog that is wrong for them in both directions: missing the things they eat, and cluttered with units they never say. Tagging the unit means the food is global and the vocabulary is local. Rice is rice. Whether you are offered a bowl, a cup or a katori depends on where you are, and it is a preference you can change, not a fact we infer from your phone number.

But is 45 grams even right?

No. Not for your roti specifically. Somebody's roti is 38 grams and somebody's is 58, and if you made them yourself this week you might know which.

The honest framing is that there are two sources of error here and they are not the same size. There is the error in the assumed weight of a standard portion, which is maybe ten or fifteen percent either way and averages out across a week. And there is the error from not logging at all, which is one hundred percent.

An app that demands precision it cannot get produces the second error while feeling rigorous. An app that accepts a named portion produces the first error and keeps the log alive. Over a month the second app knows far more about you than the first one does, and the difference is not close.

For people who do want precision, grams are always there. Tap the unit and type the number. The point is not that grams are bad. The point is that grams are a power-user affordance sitting in the default slot, and moving them out of it is most of the fight.

The photo question

The obvious answer to all of this is to point a camera at the plate. We do that too, and we are careful about what we claim for it.

Published work on automatic portion estimation from a single photo puts accuracy in the region of 39 percent. That is useful as a starting guess and unacceptable as an answer. So in our app, photo recognition proposes: it identifies the dish, picks the most likely portion, and puts a number in front of you. You confirm it, always. There is no path through the app where a photo silently writes a portion into your log.

What it cost to build this way

Household units are more work than grams in every direction. Every food needs its unit rows authored rather than derived. Every unit row needs its locale list checked. Search has to match on unit vocabulary as well as food names, so that typing "katori dal" finds the right thing. The catalog ships to the device as a versioned delta, and adding a unit row is a catalog version bump like any other change.

And there is a long tail that never ends. A new market means a new vocabulary, not just a new set of foods, and the vocabulary has to come from people who actually use it rather than from a translation of an English list.

It is the right trade. The alternative is an app that is precise about a meal you did not log.