Ask someone in Lucknow how much dal they had at lunch and they won’t say 180 grams. They’ll say one katori. Maybe a katori and a bit. If your nutrition app only accepts grams, that person guesses, guesses wrong, and stops logging by Thursday. Picking an Indian food calorie database is the first big decision in an Indian nutrition app. The second one, turning that data into portions people recognise, is where most apps lose their users.
Where Indian food calorie data comes from
There are three sources worth knowing before anyone writes code.
- IFCT 2017 (Indian Food Composition Tables), published by ICMR’s National Institute of Nutrition (NIN) in Hyderabad. It covers 528 foods with analysed nutrient values, measured from samples collected across India rather than copied from foreign tables. The catch is that these are raw ingredients. Raw toor dal, raw basmati, raw spinach. Nobody eats raw toor dal.
- INDB (Indian Nutrient Databank), described in a 2024 paper in Current Developments in Nutrition. It starts from IFCT 2017, fills gaps from IFCT 2004 and UK and US nutrient databases, and adds around 1,014 commonly eaten recipes on top of roughly 1,095 individual food items. This is the layer that gets you from raw dal to dal tadka.
- NIN’s other publications, such as the older Nutritive Value of Indian Foods tables and the Dietary Guidelines for Indians. They’re useful context for typical servings and recommended intakes.
Plenty of teams start with a generic global database because it has a nice API. Then they find paneer butter masala has five entries with wildly different numbers, each one user-submitted from a different restaurant. Generic databases are fine for packaged foods with barcodes. For home-cooked Indian food you want values traceable to IFCT, recipe-level data in the INDB style, and a clear record of which number came from where.
Recipes are the hard part
A raw-ingredient table can’t tell you what’s in a home-cooked rajma, because rajma depends on the cook. How much oil went into the tadka? Was it cooked down or left soupy? Recipe databases handle this by standardising a recipe, computing nutrients from the ingredients and adjusting for cooking yield (water lost or absorbed). Skip the yield step and the numbers drift badly: rice gains a lot of weight when it’s cooked, so a per-100 g value for raw rice applied to a cooked serving overstates the calories.
Questions to ask about any dataset you license or build:
- Is each value tagged with its source (IFCT 2017, INDB, a lab report, a brand label)?
- Are cooked dishes computed from a stated recipe, with yield factors?
- Are regional variants separate entries? Sambar at home in Chennai and sambar in a Bengaluru office canteen aren’t the same dish.
- Can you correct an entry without shipping an app release, and keep a history of the change?
Why katori, bowl and glass portions matter in an Indian food calorie database
This is the part that decides retention. A katori isn’t a standard unit. The small steel katori in one home holds less than the ceramic bowl in another, and one glass of lassi depends entirely on the glass. So the app has two jobs: accept the unit the user thinks in, and map it to grams with an assumption the user can see and change.
In practice each food carries its own portion table instead of one global “katori = X grams” constant. A katori of dal and a katori of dry sabzi weigh different amounts because their density differs. Rotis are counted, not weighed. Rice might be logged by katori or by plate, drinks by glass. Then you let the user calibrate once (“my katori is the small steel one”) and carry that forward.
We built this into Crumb Count, a nutrition app made for Indian kitchens. Its offline catalogue holds 6,410 foods, and portions are logged in katori, bowl and glass instead of forcing grams on anyone. The catalogue lives on the device, so logging still works in a basement canteen with no signal, which comes up more often than you’d expect.
Where AI fits, and where it shouldn’t
AI meal logging (type “2 roti, dal, aloo gobhi” or take a photo) is usually the first feature founders ask about. It’s useful, but the model should identify and estimate, not act as the source of calorie truth. The pattern that holds up: the model parses the meal into food names and portion guesses, your code matches those to entries in your own database, and the numbers come from the database with their sources intact. If the model makes up a calorie figure, you can’t audit it and you can’t fix it.
Two more things to settle early. The model call has to go through your server, never straight from the app with an embedded key. Crumb Count does this through a server-side proxy with per-user quotas and a model choice the server owns. And on iOS, Apple’s App Review Guidelines require you to disclose when personal data goes to a third-party AI and get explicit permission first, while health apps have to back accuracy claims with disclosed data and methodology. A database where every row has a source makes the second requirement much easier to meet.
Users notice this too. Crumb Count cites a published model for every calorie-burn number, because people trust a figure they can check.
A sensible build order
- Pick your base data (IFCT 2017 for ingredients, an INDB-style recipe layer for dishes) and tag every row with its source.
- Define per-food portion tables in the units your users actually say: katori, bowl, glass, piece, plate.
- Build manual logging and search first, with Hindi and regional names as aliases (aloo, batata, urulaikizhangu all point to potato).
- Add AI parsing on top, mapped back to your own entries and routed through a server.
- Give your team an admin console so a wrong entry gets fixed in minutes, not in the next release.
If you’re planning an Indian nutrition app and want a second opinion on the data model or the AI layer, orithLabs has shipped one, and the people who scope the work are the ones who write it. Our AI integration page explains how we approach the model side. Get in touch if it’s useful.