Industry

Prototype

Client

NutriTrack AI Calorie Tracker

From Problem to Product

The Problem During my own weight-loss journey, I realised that tracking calories consistently was harder than sticking to the diet itself. Most calorie tracking apps offered a good experience only after purchasing a premium subscription, while Indian homemade meals like dal, poha, sabzi, besan chilla or rajma either had inaccurate nutrition information or were missing altogether. Logging meals manually also became repetitive, making it easy to lose the habit after a few days. This led me to the following problem statement: "How might we help Indian users track their nutrition accurately without making the experience expensive or time-consuming?" Target Users NutriTrack is designed for people who want to build healthier eating habits without paying for premium calorie tracking apps. Primary users include: • People trying to lose or maintain weight • Gym-goers tracking calories and protein intake • Users who primarily eat Indian home-cooked meals • Beginners who need guidance rather than just calorie numbers User Stories The product was designed around a few core user stories. • As a user, I want to log my meals in less than 30 seconds. • As an Indian user, I want accurate estimates for homemade food. • As someone tracking fitness, I want to monitor calories and macros together. • As a beginner, I want suggestions on what to eat instead of only seeing remaining calories. • As someone sharing a device with family members, I want separate food histories without creating multiple accounts. Product Vision NutriTrack is an AI-powered calorie tracker that combines verified nutrition databases with AI to reduce the effort required to consistently track food. Instead of only helping users record calories, the product also guides them towards better food choices through personalised meal recommendations. Features: AI Food Recognition Users can upload a meal photo, and AI detects multiple food items, estimates portion sizes and calculates calories and macronutrients. Each detected item can be edited, removed or resized before logging. Why? Most meals contain multiple dishes rather than a single food item. Detecting each component separately significantly reduces manual effort while improving accuracy. Hybrid Food Search Every food search first queries Open Food Facts for verified nutritional information. If no reliable result exists, particularly for homemade Indian meals, the app falls back to Groq AI to generate nutrition estimates. Results are clearly labelled as either Verified or AI Estimate, giving users confidence in the data source. Personalised Nutrition Goals Rather than asking users to manually select calorie targets, NutriTrack calculates personalised calorie and macronutrient goals using the Mifflin–St Jeor Equation. Basal Metabolic Rate (BMR) For men BMR = (10 × Weight) + (6.25 × Height) − (5 × Age) + 5 For women BMR = (10 × Weight) + (6.25 × Height) − (5 × Age) − 161 Daily calorie expenditure is estimated using TDEE = BMR × 1.55 Goal-based calorie targets are then generated as: Lose Weight → TDEE − 500 kcal Maintain Weight → TDEE Gain Muscle → TDEE + 300 kcal Macronutrient targets are calculated using: Protein: 1.4–1.8 g/kg body weight Fat: ~27% of daily calories Remaining calories allocated to carbohydrates This removes guesswork and provides every user with nutrition goals tailored to their body and fitness objective. AI Meal Recommendations Most calorie trackers stop after telling users how many calories remain. NutriTrack instead analyses remaining calories, remaining macros and meals already consumed to recommend foods that best fit the user's daily goals. This shifts the experience from passive tracking to active nutritional guidance. Food History A calendar-based history allows users to review previous days, encouraging consistency rather than focusing on a single day's progress. Success metrics I'm building toward Log a meal in under 30 seconds AI search accuracy above 90% Day 7 retention above 30% Food detection precision above 85% Scope of the MVP To keep the MVP focused on validating the core problem, I intentionally excluded: Barcode scanning Cloud synchronisation Wearable integrations Social challenges Recipe generation Premium subscriptions These features were deferred because they did not directly contribute to reducing the effort required to log meals. Constraints that shaped these calls No backend: shippable solo in days, at the cost of cross-device sync. Browser storage only: zero infra cost, but data doesn't survive a cleared cache. Limited AI training data on Indian regional dishes: real coverage, variable accuracy, hence the Verified/AI Estimate split. Built solo, limited time: forced ruthless scope cuts.

Product Decisions, Trade-offs & Learnings

Key Product Decisions Hybrid Database + AI AI provides broad food coverage but can generate inconsistent nutritional estimates. Nutrition databases provide higher accuracy but often lack Indian homemade dishes. Using verified nutrition whenever available and AI only when necessary created a balance between accuracy and coverage. Local-first Architecture All user data is stored locally instead of using a backend database. Benefits • Faster development • Lower infrastructure cost • Better offline responsiveness • Simpler MVP Trade-off • No cloud backup or cross-device synchronisation. • No Authentication • Account creation increases onboarding friction. For the prototype, allowing users to begin tracking immediately was more valuable than supporting cloud accounts. Explainable AI: AI estimates are clearly distinguished from verified nutritional information. Instead of presenting AI outputs as facts, users understand when the app is providing an estimate. This improves transparency and trust. Recommendation-first Experience: Instead of ending the experience after logging food, NutriTrack continues helping users by recommending meals that fit their remaining calorie and macro budget. The product therefore supports decision-making rather than simply recording information. North Star Metric Meals logged per active user per week This directly measures whether the product becomes part of a user's daily routine. Acquisition • Visitor → Onboarding completion • Onboarding → First meal logged conversion • Time to first logged meal Engagement • Average meals logged per day • AI image uploads vs manual searches • AI meal recommendation acceptance rate • Average time required to log a meal Retention • Day 1 retention • Day 7 retention • Day 30 retention • Weekly Active Users Product Quality • Percentage of searches requiring AI fallback • AI correction rate after image recognition • User satisfaction with AI meal recommendations Built a structured eval plan rather than assuming the AI works: photo detection, search, meal suggestions, and failure handling, each with its own test scenarios and edge cases. Results so far Photo detection: 16/20 correct, 0 hallucinated items Meal auto-tagging: 7/10 correct Search source selection: 6/10 correct Finding 1: a wrong Verified badge is more dangerous than a wrong AI estimate. "banana" and "egg" correctly fall back to AI and give accurate results. "fruit banana" and "eggs" hit Open Food Facts instead and return banana chips, a smoothie, mayonnaise, and cheese, all labelled Verified, none correct. Then "apple", singular, no modifier, broke my first theory that this was about singular vs plural. It also hit Open Food Facts and returned an oat bar and a cake filling, both Verified, neither an apple. Revised root cause: Open Food Facts rarely has a clean raw-ingredient entry. The AI fallback only fires when Open Food Facts returns zero matches, which is closer to luck than a real filter. Whenever it returns anything, even an irrelevant packaged product, it wins as Verified with no check for whether it's even the same category of food. An AI guess admits it's a guess. A wrong Verified badge doesn't. Finding 2: photo detection over-decomposes some composite dishes. A photo of white sauce pasta was split into raw ingredients instead of returned as one dish, the opposite failure to the thali case. Splitting is correct for genuinely separate dishes on a plate, wrong for one cooked, composite dish. Finding 3: fixed monotonous refreshes without breaking the veg/non-veg rule. Refresh kept returning near-identical suggestions because sampling temperature was set to 0.4, biasing the model toward its single most likely output. Raised to 0.9 for real variety. The veg/non-veg split stayed a fixed rule rather than left to chance, so increasing randomness for variety didn't risk breaking the one constraint that actually matters to users. Still needs a re-test against macro relevance now that temperature changed. Product impact: Logging a photographed thali now takes well under 30 seconds, versus the 2 to 3 minutes of manual searches it replaced. Directional signal from my own use, not yet measured across other users. Key decisions Chose hybrid search over AI-only, to keep trust where it's cheap and label it clearly where it isn't. Deferred cloud sync, to validate the core experience before investing in infrastructure. Labelled AI estimates separately from Verified data, so the badge reflects data quality honestly.

Create a free website with Framer, the website builder loved by startups, designers and agencies.