BodyShody

Meal
Sign-in
FitGemini
Insights
Progress
Settings

Inspiration

The idea started from a simple frustration: most fitness apps make you type everything — every meal, every set, every rep — into tiny form fields, and most "AI coaches" are just chatbots hidden three menus deep. I wanted something that felt closer to actually having a coach: point your camera at your food, or just talk out loud about how your day went, and let the app do the bookkeeping.

The name itself is a small joke on that idea — body + shoddy — a nod to the fact that fitness tracking is usually messy, inconsistent, and easy to abandon. The goal was to make the tracking effortless enough that the consistency takes care of itself.

How I built it

Frontend: Plain HTML + Tailwind CSS + vanilla JavaScript across nine linked pages, sharing a consistent sidebar, color system, and dark/light theme (persisted per device). AI Layer: Google's Gemini API, used two ways — Text + voice, for the FitGemini coach: a running conversation held in memory, spoken aloud via SpeechSynthesisUtterance and listened to via SpeechRecognition. Vision, for the meal photo analyzer: a photo is base64-encoded and sent with a strict "reply only with JSON" prompt, then parsed straight into the Add Meal form. State & persistence: No backend database — meals, workouts, water intake, theme, and the uploaded avatar all live in localStorage, keeping the whole thing deployable as static files. Deployment path: Designed to run either as plain static HTML (open and go) or on Vercel, where an /api/gemini serverless function proxies requests using a server-side key — so a real deployment doesn't require every visitor to bring their own API key.

Challenges we ran into

Models don't stay still. Midway through, the Gemini model I'd hard-coded (gemini-2.0-flash) was deprecated — a good reminder that AI-integrated apps need to treat the model name itself as a config value, not a constant. Quota limits are real. Hitting a 429 quota error on the free tier while testing the meal analyzer forced me to build a proxy architecture I hadn't originally planned for — which ended up making the whole app more production-ready than the "just paste your key" version. Recalculating everything, live. Once meals and exercises became addable instead of static, every dependent number — macro rings, nutrient bars, meal-distribution percentages, workout volume — had to recompute correctly and instantly, without breaking the layout. Voice reliability across browsers. The Web Speech API is genuinely inconsistent — solid in Chrome, unsupported in Safari/Firefox — which is why FitGemini also supports typing a message as a fallback, so the coach is never actually unreachable.