I wanted to add nutrition tracking to a fitness app. Every API I found either:
- Charged $449/month (Nutritionix)
- Hid protein data behind paywalls
- Returned incomplete data
So I did what any reasonable developer would do: I built my own.
Here's the honest journey.
Month 1: The Naive Beginning
Goal: "Just wrap the USDA API, how hard can it be?"
Reality: Very hard.
The USDA API is powerful but raw. To make it developer-friendly, I needed:
- Natural language parsing
- Unit conversion (cups to grams)
- Multi-ingredient aggregation
- Error handling for thousands of edge cases
I underestimated every single part.
Month 2: The Architecture Decision
I chose Cloudflare Workers because:
- Edge computing = fast
- Generous free tier
- D1 database included
- No cold starts
The tech stack:
- Runtime: Cloudflare Workers (TypeScript)
- Database: D1 (SQLite) + KV (cache)
- API Gateway: RapidAPI (monetization)
Result: <100ms for 98% of requests.
Month 3: The Data Quality Crisis
Users found bugs:
- "Fat values don't add up"
- "Missing vitamins for some foods"
- "100g chicken has 500 calories??"
I spent an entire month on data validation:
- Cross-checking against USDA
- Adding hierarchical fat breakdown
- Building nutrient schema validation
Month 4: Launch Prep
Created:
- Landing page (GitHub Pages, free)
- Documentation
- SDKs (Python, JavaScript, Java)
- RapidAPI listing
What Actually Worked
- Reddit posts - 70% of my traffic
- Comparison table - Shows clear value
- Free tier that works - 25 nutrients, not 5
- Fast responses - People notice <100ms
Lessons for Other Builders
- Solve your own problem - You understand it best
- Don't over-engineer - Ship, then improve
- Free tier matters - Let people try before buying
- Community is everything - Reddit, Indie Hackers, Twitter
Get the Code
Nutrition Tracker API - SDK : GitHub
Building something? I'd love to hear about it in the comments.
If you want to try the API: Nutrition Tracker API on RapidAPI
Top comments (1)
Under the hood we run on Cloudflare Workers with a lean, rules-based parser, heavy use of KV/Cache (ETags, SWR), request coalescing, and Unbound + Queues with waitUntil for the chunky stuff-keeping P95 latency at <100 ms worldwide. Data chills in D1 and KV with a tiny Durable Object just for rate limiting and stampede control. The REST API is straight‑shooting-clear errors, idempotency keys, URI versioning-and we keep it sturdy with Honeycomb traces, Sentry, synthetics, chaos drills, and a graceful fallback to stale cache or generic items when things go sideways. On the security and biz side: hashed keys, edge rate limits/quotas, log scrubbing, GDPR/CCPA flows.