How I Built CaloGlow: An AI Calorie Tracker That Actually Understands Dal Bhat

https://www.caloglow.com/

Every calorie tracker I tried had the same blind spot. I'd photograph a plate of dal bhat — rice, lentils, a vegetable curry, maybe some achar — and the app would shrug and offer me "rice (1 cup)." It had no idea what it was looking at. Logging a normal Nepali meal meant fighting the app: searching for each item, guessing portion sizes, settling for an American approximation of food I'd eaten my whole life.

So I built the tracker I wished existed. It's called CaloGlow — an AI-powered, offline-first nutrition app that understands how people in Nepal and South Asia actually eat. This is the story of how it came together, and the engineering problems that turned out to be more interesting than I expected.

The core idea: meet people where they eat

The bet behind CaloGlow was simple: logging food should take five seconds, not five minutes, and it should work for your food. That meant supporting every way someone might want to log a meal — snap a photo, type "two rotis and chicken curry," speak it out loud, or scan a barcode — and getting a real calorie, macro, and micronutrient estimate back instantly.

The hard part isn't the UI. It's making the intelligence behind it both accurate for regional cuisine and reliable enough that it never leaves the user staring at a spinner.

Problem 1: AI that doesn't fall over

My first instinct was to wire up a single vision model and call it done. That's a great demo and a fragile product. Models rate-limit you, time out, return garbage JSON, or simply don't recognize a dish. If logging a meal fails even one time in ten, people stop trusting the app — and a tracker you don't trust is a tracker you delete.

So instead of one model, I built a layered fallback pipeline. For text parsing, the app tries a fast model first, falls back to a second provider if that fails, and finally drops to a local keyword dictionary that I seeded with common Nepali dishes — so even fully offline, "dal bhat" still resolves to something sensible. For photos, it tries one vision model, then another, and routes genuinely ambiguous cases to a stronger model as a last resort.

The lesson that stuck with me: treat AI as an unreliable network dependency, not a function call. Once I designed for failure as the default case, the whole experience got dramatically more robust. Meal logging effectively never hard-fails anymore — it just degrades gracefully to the next-best answer.

Problem 2: it has to work with no signal

A nutrition app gets used in kitchens, at restaurants, on the move — exactly the places where connectivity is worst. An app that freezes the moment the bars disappear is useless.

So CaloGlow is offline-first by architecture, not as an afterthought. Every meal, every glass of water, every weight entry is written to a local database (IndexedDB, via Dexie) first. The UI updates instantly off local data. A background sync layer then pushes changes up to the cloud and pulls down anything new whenever a connection is available.

This sounds clean until you hit the edge cases, and the edge cases are where I spent real time:

• What happens when you delete a meal offline, and a sync that was already in flight tries to pull it back down? I solved this with tombstone records — deletions are tracked so a later sync can never resurrect something the user already removed.

• What happens when the same row was edited on two devices? The sync resolves by writing the freshest version and preserving local-only fields (like a photo thumbnail) that don't live in the cloud.

• How do you keep the app usable for someone who's never signed up? Every visitor gets an anonymous guest session immediately, and when they later create a real account, their guest data is merged into it.

Getting sync right is unglamorous work, but it's the difference between a toy and something you'd rely on every day.

Problem 3: feels like an app, ships like a website

I wanted CaloGlow installable on a phone's home screen, launching full-screen, working offline — without the friction of app stores. That's what a Progressive Web App delivers, so I built it as one.

A service worker (via Workbox) pre-caches the app shell and uses a network-first strategy for live data with a short timeout, so the app loads instantly and stays current. The result installs like a native app and updates silently in the background, but ships from a single codebase to every platform.

This choice also taught me where the web platform still has sharp edges. iOS, for instance, runs an installed PWA in its own isolated container and won't let an external link open into it — a limitation with no real workaround that shaped how I designed features like meal sharing. Knowing the boundaries of your platform is just as important as knowing its capabilities.

Beyond the tracker: building a real product

A logging screen isn't a product. To make CaloGlow something people would actually keep, I built the surrounding system:

• Personalized targets — calorie and macro goals derived from the user's body stats and goals using the Mifflin–St Jeor formula.

• A micronutrient breakdown — AI-estimated vitamins and minerals scored against daily reference intakes, so it's more than just a calorie counter.

• An AI nutrition coach — a conversational assistant for questions and guidance.

• Health integrations — water and step tracking with Google Fit sync, weight logging, and optional cycle tracking.

• A growth and subscription layer — free trials, behavioral engagement scoring that nudges users at the right moments, a referral program, and monthly/annual plans with feature gating.

Each of these is a small system of its own, and stitching them together taught me as much about product thinking as about code.

The stack

CaloGlow is built with React, TypeScript, and Vite, styled with a token-based Tailwind design system that supports light and dark themes. State lives in Zustand; local persistence runs on Dexie / IndexedDB. The backend is Supabase — authentication, a Postgres database secured with Row-Level Security, and edge functions for server-side logic. The AI layer spans multiple providers for text, vision, and coaching, with Open Food Facts for barcode lookups, Google Fit for steps, and a Merchant-of-Record provider for payments.

What I took away from it

CaloGlow started as a personal annoyance and turned into a crash course in building software that survives the real world: AI that's allowed to fail, data that lives on the device first, and a web app that behaves like a native one. The most valuable lessons weren't about any single technology — they were about designing for the messy conditions where the app actually gets used.

And the best part? I can finally log my dal bhat in five seconds.