Nutrition tracking built around the food Indians actually eat.
Daily meals · Macro clarity · Restaurant guidance
Most calorie-tracking apps can scan barcodes. Most cannot tell you how much protein is in a home-cooked bowl of dal chawal, a thali from the canteen, or a plate of curd rice. ByteCal is a nutrition companion built for the way people in India actually eat — at home, at restaurants, and everywhere in between.
This is an independent concept prototype. The screens and flows represent design rationale and UX exploration. No user research, usability testing, or live product metrics have been performed or are claimed.
The food millions of people eat every day is invisible to most tracking apps.
Nutrition tracking has a coverage problem in the Indian context. The databases that power most apps are built around packaged foods, Western staples, and restaurant chains that publish nutritional information. Home-cooked Indian meals — which represent the majority of what most Indians eat — are poorly represented, inconsistently named, or missing entirely.
The result is a category of apps that technically works but practically fails:
- Searching for “sabji” returns no results or the wrong dish
- Logging dal requires entering chickpeas, water, oil, and spices separately
- Protein in everyday meals like rajma or chole is obscured or absent
- Restaurant guidance assumes menus with printed nutrition facts
ByteCal is a concept for a nutrition companion that treats Indian cooking as the primary use case, not an afterthought — with a food database built around dish names, regional variations, and home-cooking reality, not ingredient weight tables.
Four principles that shaped the concept.
- 01
Track what you actually cook, not what a database expects.
Most nutrition apps treat Indian food as a lookup problem — but home-cooked meals change by region, household, and season. ByteCal is designed around the real vocabulary of Indian cooking: named dishes, thali compositions, and regional variations.
- 02
Protein first, not just calories.
Calorie counting creates anxiety without direction. Protein intake is the lever most people can act on immediately. ByteCal surfaces protein remaining — not just calories consumed — as the primary feedback signal.
- 03
Log a meal, not a spreadsheet.
Logging rice and dal as separate ingredients with precise weights creates friction that breaks habits. ByteCal treats 'dal chawal' as a single, adjustable entry — matching how people actually eat and think.
- 04
Make restaurant meals a decision, not a failure.
Eating out is framed as a compliance problem in most trackers. ByteCal turns a restaurant menu into a budget-matching exercise: given what you have eaten today, which dishes here keep you on track?
Four screens, four moments that matter.
Each flow addresses a distinct user need. Annotations explain the design intent behind each screen.
Daily meal log
The daily view is organised around meals — breakfast, lunch, dinner, snacks — not macro graphs. Each entry is logged as a dish, not a spreadsheet of individual ingredients. The calorie ring and macro strip (protein, carbs, fat) sit at the top — with protein given equal prominence to total calories.
Activity and meal timeline
The activity view surfaces today's meals as a timestamped schedule, making it easy to see what's been eaten and what's coming. Completed meals are marked; pending meals show a clear 'mark as eaten' action. The timeline framing reinforces that logging is a daily rhythm, not a one-off task.
Food discovery and search
The Discover screen is a browse-first, search-second approach to finding meals. Filter chips (High Protein, Vegan, Low Carb) let users narrow without typing. Each result surfaces calorie count and protein grams as the two primary signals — not a full macro breakdown that would add noise.
Meal scanner
The scanner turns the camera into a logging shortcut — point it at food, a QR code, a food label, or a nutrition panel. This addresses the key friction point in mobile tracking: the time it takes to find and log a meal while you're eating. Four modes give flexibility without complexity.
Constraints that kept the concept honest.
Three things that would have undermined the product's core promise.
- 01
No gamification or streaks
Streak mechanics create anxiety around missed days and prioritise consistency over accuracy. Sustainable awareness does not require a reward system — it requires a tool that is fast enough to use every day.
- 02
No barcode-only scanning as the primary entry method
Barcode scanning works well for packaged foods but misses the majority of how people in India eat: fresh produce, home-cooked dishes, street food, and meals without packaging. Scanning can supplement; it cannot be the core.
- 03
No 'diet food' substitution suggestions
Suggesting quinoa or protein powder as substitutes for dal or rice is not useful — it signals that the user's existing diet is wrong. ByteCal works with what users already eat and helps them understand it, not replace it.
The thinking behind the concept.
- 01Familiar food is a feature. The product should meet users where they eat, not where a nutritionist expects them to eat.
- 02Speed of logging matters more than precision. A 90%-accurate entry made in ten seconds is more valuable than a perfect entry that takes two minutes and gets skipped.
- 03Protein awareness builds agency. Most users do not need to optimise every macro — they need to understand the one lever they are currently missing.