TrackWell

The problem

Calorie tracking apps fall into two camps. The free ones make you type every meal and the paid ones lock useful features behind a subscription. Neither handles Indian food well, and most ignore outdoor activity tracking unless you wear a fitness band. TrackWell collapses the workflow: snap a photo of your plate, get calories and macros back, and let the app handle hydration, exercise logging, and walks in the same place. The user does the minimum work and the AI does the rest.

Architecture

The app is React Native on Expo SDK 54 with file-based routing via Expo Router v6. Auth is Clerk (email plus Google OAuth) with secure token storage. State persists to Firebase Firestore under a per-user document tree (logs by date, weight history, GPS activities, notification history). Local AsyncStorage caches recent reads to keep the home screen instant on cold open.

Three separate Gemini integrations handle the AI work, each with its own service module. The food vision pipeline (foodAiService.ts) takes a camera image and returns structured JSON for food name, serving size, and macros. The plan generation pipeline (generating.tsx) runs once during onboarding and writes the result to the user document. The weekly insights pipeline (analyticsAiService.ts) packages 7 days of logs and asks Gemini for a health score, behavioural patterns, and a written summary, with the response cached for 6 hours per user.

The GPS tracker uses Expo Location's foreground watcher at high accuracy. Distance is computed pairwise between coordinate samples using the Haversine formula. Calorie burn comes from a MET value scaled by the user's logged weight and elapsed time, not a fixed kcal-per-km constant. Activities are saved as their own documents in Firestore so they show up in the recent activity feed and roll into the daily calorie balance.

Hardest technical decision

Caching the weekly AI insights for 6 hours rather than regenerating on demand. The pull was real on both sides. Live insights every time the user opens the analytics screen would feel premium and always-fresh, but Gemini calls cost money and add a 3 to 5 second wait on a screen that should feel instant. Caching forever would be cheap and fast but would make the insights stale the moment the user logs a new meal. I picked 6 hours as the trade-off because the underlying signal (a week's worth of behaviour) doesn't move meaningfully on a sub-day scale, and 6 hours guarantees the user sees a refresh at least once per active day. The cache key is per-user and invalidates on the next read after expiry, which means the cost of a stale read is one unnecessary cache check, not a silent stale render. If I were building this for a paid tier later, I'd flip the strategy: live insights for paid users, 6-hour cache for free.

What I'd do differently

Build a single AI service layer instead of three independent integrations. Right now the food vision, plan generation, and weekly insights pipelines each maintain their own prompt strings, response parsing, and error handling. They drift over time. A unified geminiClient.ts with typed request and response schemas, retries, and a consistent error envelope would have prevented the three slightly different failure modes I have today (food recognition silently returns nulls on a bad image, plan generation throws on malformed JSON, weekly insights returns a partial object with some fields empty). I would also move the FatSecret OAuth 1.0 signing to a tiny serverless proxy. Doing OAuth 1.0 from the mobile client means the consumer secret ships in the bundle, which is fine for a portfolio project but unacceptable for a real public release.