I built a free multilingual AI nutrition tracker solo — launching on Product Hunt today!
I just launched goNutriTrack on Product Hunt today — would love your support!
https://www.producthunt.com/posts/gonutritrack
goNutriTrack is a free multilingual AI nutrition tracker I built solo over the past few months. Here's what makes it different:
- 🌍 Works in Greek, English, German, French & Spanish
- 🤖 AI food recognition from photos
- 🎤 Voice logging — say what you ate, AI parses it
- 👨🍳 Recipe analyzer — paste ingredients, get macros per serving
- 💪 Gym tracker with rest timer & exercise stopwatch
- 🤖 AI Coach that knows your meals, goals and workout history
- 📊 Streaks, barcode scanner, PDF export
Tech stack: React + Vite PWA, Supabase, Cloudflare Workers, Anthropic API (Claude Haiku for voice/recipe, Sonnet for photo recognition & coaching).
It's 100% free, no install needed — works as a PWA on any device.
Happy to answer any questions about the stack or the build process!
Trending on Indie Hackers
Nice launch. One metric I would add beyond signups/PH clicks is “edited after AI guess” by input type: photo, voice, recipe, barcode. In food logging, trust is built less by perfect first guesses and more by making corrections obvious, fast, and remembered the next time. I’m working in the same AI food logging space, and that correction loop feels like the real retention lever after the novelty fades.
Nice work — the multilingual angle is underrated, most solo apps ship English-only and lose half the world. I'm building a multilingual app too (budget + safety for travelers) and the i18n upkeep is real once you add features.
Quick q: did you go PWA over native specifically to dodge the app-store friction? I went React Native + APK and the distribution side has been the hardest part. Curious how Product Hunt is converting for you so far — good luck with the launch!
Thanks! Yeah, I went PWA very intentionally. The main reason was to avoid the whole native distribution pipeline — signing keys, bundle formats, Play Store review cycles, policy compliance, device‑specific bugs, and the constant overhead of shipping updates through gated channels.
With a PWA I get:
instant deploys (no review queue)
atomic updates (no version fragmentation)
one codebase, one build target
no APK hosting or sideloading friction
no native store policies throttling releases
The trade‑offs are obvious — limited access to native APIs, no deep OS‑level integrations, and some UX constraints — but for this product’s scope it was a net win.
I’ve shipped React Native + APK before and I totally feel your pain: distribution is the hardest part, especially when you’re outside the Play Store ecosystem. Getting users to trust and install an APK is a conversion killer.
As for Product Hunt, the traffic is solid but conversion is naturally lower — lots of curiosity clicks, fewer people who actually try the app. Still, it’s good signal and early‑stage feedback.
Good luck with your launch as well — always nice to see more indie devs shipping.
This is a solid scope for a solo build — especially combining food logging, voice input, and coaching in one system.
What stands out most is the multimodal angle (photo + voice + text). That’s usually where these apps start to feel “sticky,” because logging effort drops significantly compared to traditional nutrition trackers.
The main challenge I’d watch is retention vs novelty. A lot of AI nutrition tools get initial excitement, but long-term usage depends on how accurate the tracking feels and how frictionless daily logging becomes after the first week.
Also interesting stack choice with Haiku vs Sonnet split — that’s a smart way to balance cost and performance for different tasks.
Overall, the value proposition is clear: reducing friction in tracking + making it conversational instead of manual logging. That’s usually what actually changes user behavior.
Appreciate it! Yeah, the whole idea was to reduce logging friction as much as possible — multimodal input helps a ton there. Retention is definitely the real challenge, so I’m focusing on accuracy + minimizing daily effort after the novelty wears off. And yep, the Haiku/Sonnet split has been a nice balance so far in terms of cost vs performance.
Tried the guest experience for a few minutes and one thing that stood out is that the homepage doesn't immediately communicate the product's strongest differentiator.
After landing on the dashboard, I mostly saw empty nutrition metrics and tracking controls, but the AI photo logging / voice logging capabilities that make the product unique weren't immediately obvious.
As a first-time user, I found myself wondering:
"What's the first thing you want me to do?"
A stronger first-run experience that guides users toward logging their first meal (especially with AI) might help users reach the "aha" moment faster.
The multilingual positioning is interesting though — that's not something you see very often in this category.
Thanks for the thoughtful feedback — totally fair point. Right now the dashboard loads first because I wanted the “daily view” to feel lightweight, but I agree it hides the strongest differentiator. I’m already working on a more guided first‑run flow that pushes users straight into their first AI meal log so they hit the “aha” moment faster. The multilingual angle is something I’m doubling down on too, since it seems to resonate with non‑EN users. Appreciate you taking the time to try the guest flow.
Interesting build.
What I'd be most curious about isn't the food recognition itself, but which part users come back for after the novelty wears off.
A lot of health products get initial engagement. The harder part is figuring out what creates the second and third week of usage.
Totally agree — that’s the real question. The recognition is cool for week one, but what I’m trying to validate is which interaction becomes the “default habit” once the novelty fades. My guess is it’ll be whichever input mode feels lowest‑effort in real life (photo vs voice vs quick‑add), but I’m watching the second‑ and third‑week retention closely to see what actually sticks.
Possibly.
The reason I'd be careful is that I don't think the interesting part is which input mode ends up winning.
I think there's a more important decision sitting underneath that assumption.
I wouldn't try to unpack that properly in a thread.
If you'd like the tighter version, drop your email and I'll put it together properly.