Building MyFatnessPal: How I Made Nutrition Tracking Effortless

MyFatnessPal demo

Thesis: Food logging fails because it fights human behaviour. An AI that understands plain English makes tracking fast enough to stick.

The Problem We All Ignore

I’ve tried MyFitnessPal, Cronometer, and a dozen others. Same pattern every time: great intentions, abandoned in weeks.

The reason? Food logging sucks.

Not the idea, tracking what you eat is valuable. The process is the problem: hunting through databases, guessing portions, adding oils and sauces as separate entries. Five minutes later, you’ve logged one “simple” salad.

Plenty of user research points to high early abandonment for nutrition apps. The friction is too high. The payoff feels too far away.

So I built something different.

The Vision: Talk to Your Food Log

What if logging food was as easy as texting?

“Chicken caesar salad with light dressing.”

That’s it. No measuring cups. No barcode scanning. Just describe what you ate. Let AI do the boring parts.

MyFatnessPal (yes, the name is a joke) understands natural language and returns structured nutrition data from plain-English descriptions.

Result: food logging that’s dramatically faster and surprisingly accurate for complex meals.

How It Works (AI-First, Not Database-First)

Under the hood, MyFatnessPal uses a lightweight GPT model to parse your description and:

  1. Identify ingredients (e.g., romaine, grilled chicken, parmesan, croutons, dressing)
  2. Estimate reasonable portions from context
  3. Calculate calories and macros (protein, carbs, fat)
  4. Return structured data to populate your log

It shines on: – Restaurant meals: “Chipotle bowl with chicken, no rice.” – Home cooking: “Mom’s beef stew, about two cups.” – Snacks: “Handful of almonds and an apple.”

It isn’t perfect, but it’s often more useful than manual database hunting and fast enough to use daily.

Tech Stack (Deliberately Boring)

No microservices. No GraphQL. No frontend build maze. Just clean Django and modern tooling.

Why it matters: quick boots, millisecond-fast tests, single-container deploy, ~170 well-tested files.

Features That Reduce Friction

1) Quick-Add Recent Foods

Re-log repeating meals with one click.

2) Recipe Management

Save ingredients → auto per-serving nutrition → log a serving instantly.

3) Visual Daily Summary

Progress bars for calories, quick charts for macros, color-coded guidance.

4) Edit Anything

Fix mistakes, add dessert after dinner—no wrestling with the UI.

Development Philosophy: TDD or Nothing

Every feature started as a test:

What Makes This Different

Versus MyFitnessPal/Cronometer
– Them: database search, manual portions, 5–10 min/meal
– Me: natural language + AI estimation, ~30 sec/meal

Versus Social Fitness Apps
– Them: feeds and gamification
– Me: private by default—honest tracking without judgment

Versus Feature-Heavy Suites
– Them: everything plus the kitchen sink
– Me: one thing done extremely well—effortless logging

The Numbers (Post-MVP)

What I Learned

  1. AI isn’t magic, but it’s great at fuzzy tasks.
    “Good enough, fast” beats “maybe precise, slow.”

  2. TDD feels slow—until it saves your week.
    Fewer bugs, safer refactors, cleaner design.

  3. Simplicity scales.
    Every feature I didn’t build is maintenance I don’t owe.

  4. Developer tools matter.
    Agent OS turned planning into executable specs.

What’s Next

Truth is, the app is already useful. I use it daily. Friends keep using it. That’s the metric that matters.

Try It (Eventually)

It’s a personal project for now. I may open-source it or offer a hosted version. If you’re into:

Reach out. I’m happy to share details and war stories.

Next Steps (High-Level): Add MCP Integration

Goal: expose MyFatnessPal to AI assistants via Model Context Protocol (MCP) so they can log meals, fetch summaries, and manage recipes on your behalf.

Plan (no code, just the map): 1. Agree on Capabilities
– Tools: log_food, getdailysummary, recent_entries, logrecipeserving.
– Optional: find_recipe, create_recipe (later).

  1. Stabilize a Minimal API

    • One endpoint to accept a free-text meal and return structured nutrition.
    • One endpoint to fetch daily summaries by date.
    • Endpoints for recent items and recipe logging.

  2. Choose MCP Transport & Runtime

    • Start with stdio for local use; graduate to HTTP if you need remote calls.
    • Pick TypeScript or Python—whatever your team can maintain comfortably.

  3. Define Contracts

    • Tight, human-readable JSON schemas for inputs/outputs.
    • Clear error shapes (including “AI could not infer portions”).

  4. Auth & Safety

    • Scoped tokens (read vs write).
    • Per-token rate limits and audit logs.
    • Idempotency keys for create/log operations.

  5. Privacy by Default

    • No sharing without explicit user intent.
    • Redact PII from logs; short retention for raw prompts if you store them at all.

  6. Observability

    • Request IDs, structured logs, minimal metrics: success rate, latency, error classes.
    • Trace from assistant prompt → MCP tool → app result.

  7. Resilience

    • Retries with backoff on transient failures.
    • Circuit breaker if the AI service is degraded.
    • Graceful fallbacks (e.g., save raw text entry unparsed).

  8. Testing

    • Contract tests against the API.
    • Golden-file tests for typical meals (restaurant, home-cooked, snack).
    • Load test a “busy evening” scenario.

  9. Launch Steps

    • Ship v0 privately to power users.
    • Collect feedback on tool names and result shapes.
    • Iterate, then publish a lightweight “how to connect” guide.

Appendix

Tech Stack: Django 5.1, Python 3.12, OpenAI, Tailwind, pytest
Time: Two phases, ~3 weeks
Coverage: ~85% with 170+ tests
Status: Fully functional MVP with recipe management