NutriForge Build Plan
Private build plan. Enter hub password to continue.
That's not right. Try again.
NutriForge Build Plan
Ingredient list in, per-serving macros and micros out. Built on public-domain USDA data, so it's your data: store it, publish it, print it, own it.
1. Vision & Positioning
The wedgeNutriForge is a developer-facing nutrition-analysis API. You POST a recipe's free-text ingredient list (plus title and servings) and get back full per-serving nutrition: the seven macros (calories, protein, carbs, fat, fiber, sugar, sodium) plus a broad micronutrient panel (iron, calcium, potassium, zinc, magnesium, vitamins). It does the hard parts: parse each messy line, match it to a food, convert the portion to grams, scale, sum, and divide by servings.
We're built on public-domain USDA FoodData Central data. That one fact is the wedge, because it lets us grant rights the incumbents can't.
The two-pronged wedge:
- Data-ownership rights (the real moat). Because the data is US-government public domain, customers can STORE the computed nutrition, DISPLAY it on public sites, and PRINT it in cookbooks, with no caching limits and no attribution badge. Edamam's own terms forbid exactly this: data "can not be stored unless explicitly permitted," paid caching is capped at "only the four basic macro nutrient data points," and even those must sit "behind a password" (Edamam). NutriForge says: it's your data, forever.
- Price. Undercut Spoonacular, Edamam, and Nutritionix on the entry and mid tiers. Our COGS is structurally low because the data is free and the only per-call cost is a few hundred cheap-model tokens.
Developer-first: clean REST, one key, one POST per recipe, honest docs, a generous free tier, and a self-serve portal. The incumbents increasingly hide pricing behind "contact sales" (Nutritionix is now partner-only and quote-based, Spike API roundup). We win the long tail of small builders who just want to analyze a recipe and own the result.
Honest framing up front: the incumbents' moat is branded and restaurant foods (a Big Mac, a Starbucks latte, a specific granola brand). USDA has a Branded Foods dataset, but matching free-text to the right branded item is genuinely harder than matching a generic raw ingredient. We're strong on home-cooked, raw-ingredient recipes (most recipe-app and food-blog traffic) and weaker on packaged/restaurant lookups. We lead with the rights story and the recipe-analysis use case, not with "we have every branded SKU," because we don't.
2. Target Customers
RecipeMemoir = customer zeroThe same buyers Spoonacular and Edamam serve, biased toward the ones who need to OWN and PUBLISH their results:
- Recipe and meal-planning app developers who display nutrition in-app and on public share pages. Storage/display rights matter to them directly.
- Food bloggers and recipe-site CMS plugins. A plugin that auto-computes a nutrition label and publishes it on the blog page. Edamam's "behind a password, human-initiated" terms are openly hostile to this; our cleanest win.
- Fitness and macro-tracking apps that want per-serving macros at scale and care about cost-per-call.
- Cookbook and print/POD tooling that needs print rights Edamam doesn't grant on standard tiers.
- Customer zero: RecipeMemoir. It needs to analyze ~1,741 recipes, store the results in its own Cloudflare D1, and display them on users' public recipe sites and in printed KDP cookbooks. It currently plans to pay Spoonacular ~$29/mo. NutriForge replaces that, and is the dogfood account that proves the engine on real, messy data. The day NutriForge clears the validation bar, RecipeMemoir retires the Spoonacular fee.
3. Architecture
4 engine pieces + API layerFour engine pieces, then an API layer on Cloudflare.
- (a) USDA FoodData Central data (the food database). Public-domain, no storage/display/attribution restrictions. We host Foundation Foods + SR Legacy (authoritative generic raw ingredients, full macro+micro panels), FNDDS (survey foods and, critically, household-measure portion data), and Branded Foods (packaged products, ingested but hard to match: a phase-2 climb). Snapshotted into our own store and refreshed on USDA's release cadence.
- (b) Portion → grams (the conversion layer). The brittlest part of any engine. USDA FNDDS household-measure data gives gram weights for common portions ("1 cup, chopped", "1 medium"). A curated density table backs it up for liquids/flours/sugars. Unit normalization handles fractions, unicode, metric/imperial, "a dash", "to taste" (zero-weight, flagged), and ranges. This layer carries the most accuracy risk, so the validation bar weights it heavily.
- (c) LLM ingredient parse + food-match (the smart layer). A cheap model does two jobs classical parsers do badly: structured line parsing (turn "2 lbs boneless skinless chicken breast, cubed" into structured fields) and food-match disambiguation (pick salted vs unsalted butter from the retrieved USDA candidates). The LLM ranks candidates we retrieve; it never invents nutrition numbers (those always come from USDA), which keeps it cheap and auditable. Model: DeepSeek via OpenRouter (
deepseek/deepseek-chat) at $0.20/1M input, $0.80/1M output (OpenRouter), or DeepSeek-direct at $0.14/$0.28 once volume justifies it (DeepSeek). No premium model ever on the batch path. - (d) Aggregate ÷ servings. Sum per-line scaled panels, divide by servings, emit per-serving and whole-recipe figures, and attach a confidence score (fraction of lines matched and sized with high confidence). Low-confidence lines are flagged in the response.
API layer (Cloudflare): Workers for the HTTP API and orchestration; D1 for the hosted USDA lookup tables, accounts, keys, and usage metering; R2 as a response cache (a recipe's nutrition is deterministic given the same input, so we cache by a hash of normalized input and serve repeats for near-zero cost: the single biggest lever on COGS); per-key auth, plan-tiered rate limiting, and edge response caching that skips the LLM entirely on a hit.
4. The Validation Bar
Ship-to-sell gateWe do not sell access until NutriForge clears a documented accuracy bar. Selling an inaccurate nutrition API is a refund magnet and a reputation killer, so this is a hard gate.
How we prove accuracy: RecipeMemoir is about to run a Spoonacular backfill across its ~1,741 recipes. Spoonacular's analyzed output becomes our gold-standard answer key. We hold out a benchmark set and compare NutriForge line-for-line and per-serving against it.
The benchmark set: a held-out sample of 200 to 300 recipes, drawn to be representative across cuisines, list lengths, and messiness (clean JSON-LD lines vs hand-typed lines with prep notes). Where a recipe also has the blogger's own published per-serving nutrition, we capture that as a second reference point.
Pass thresholds (the explicit gate)
| Metric | Threshold to ship |
|---|---|
| Calories | within ±15% of gold standard on ≥90% of held-out recipes |
| Protein, carbs, fat | within ±20% each on ≥85% of recipes |
| Fiber, sugar, sodium | within ±25% each on ≥80% (noisier in every engine) |
| Per-line match rate | ≥90% of lines matched to a plausible FDC food (rest flagged, not silently wrong) |
| Micros coverage | micro panel populated on ≥75% of recipes for the core set (iron, Ca, K, Zn); honest nulls, never faked zeros |
Per-nutrient error budget. We track median and 90th-percentile percentage error per nutrient. Calories and the big-three macros get the tightest budget (it's what users notice); sodium and sugar get a looser budget because portion ambiguity makes them irreducibly noisy across every engine.
Honesty about the gold standard: Spoonacular is not ground truth, it's a strong reference. When NutriForge and Spoonacular disagree by a lot, that's a triage item, not an automatic NutriForge failure: sometimes USDA's authoritative generic data is closer to reality than Spoonacular's crowd/scraped sourcing. The bar is "we land close to a respected commercial baseline across a representative set," which is the credible, sellable claim. The gate: all five rows pass on the held-out set → we may charge. Any row fails → fix the engine (usually the gram conversion) and re-run before selling.
5. Cost Model (COGS + Pricing)
~$0.0014/request · 75%+ marginPer-request cost (avg ~10-ingredient recipe)
The only variable cost is the LLM parse/match call plus a sliver of infra. USDA data is free.
- LLM (DeepSeek via OpenRouter, conservative path): ~2,500 input tokens (stable block cached) × $0.20/1M = $0.0005; ~800 output × $0.80/1M = $0.00064. ~$0.0011 per recipe, call it ~$0.0011 to $0.0015 with overhead (OpenRouter). On DeepSeek-direct ($0.14/$0.28) it's ~$0.00058, roughly half (DeepSeek). We model the OpenRouter number to stay conservative.
- Cloudflare infra per 1,000 requests: well inside the $5/mo Workers allotment (10M requests + 30M CPU-ms included; D1 $0.50/M reads, R2 Class B $0.36/M, no egress fees). ~$0.01 to $0.03 per 1,000 requests: a rounding error next to the LLM cost (Workers, D1, R2).
Blended COGS per analyzed recipe (cache MISS): ~$0.0012 to $0.0016. Per cache HIT: ~$0.00003 (read only, no LLM). Recipes are analyzed once and cached forever, so at steady state effective COGS drops well below $0.001.
One-time backfill (RecipeMemoir, ~1,741 recipes): 1,741 × ~$0.0014 = ~$2.44 in LLM cost. The entire dogfood backfill costs a couple of dollars. (The same job on Spoonacular's Cook plan is the $29/mo subscription.)
Fixed costs
Workers Paid $5/mo (src); Resend $0 to $20/mo; Stripe ~2.9% + $0.30/charge, no monthly fee (src); domain ~$1 to $4/mo amortized. Fixed-cost floor ~$6 to $30/mo. Almost no fixed cost; the risk is demand, not infrastructure.
Proposed pricing tiers (undercut Spoonacular, keep margin)
Spoonacular direct: Free, Cook $29, Culinarian $79, Chef $149, Enterprise (src). Edamam entry $29/mo, then jumps to $299/mo (src). We slot beneath both and give away the rights Edamam charges enterprise money for.
| NutriForge tier | Price | Included / mo | Positioned against |
|---|---|---|---|
| Free / Dev | $0 | 500 analyses, full rights | Beats Spoonacular's metered free tier; no "human-initiated" strings |
| Indie | $15/mo | 10,000 analyses | ~half of Spoonacular Cook ($29) and Edamam ($29) |
| Studio | $49/mo | 50,000 analyses | Under Spoonacular Culinarian ($79) |
| Scale | $129/mo | 200,000 analyses | Under Chef ($149); far under Edamam's $299 jump |
| Enterprise | custom | volume + SLA + white-label | vs Edamam/Nutritionix enterprise quotes |
All paid tiers include the full macro + micro panel and full data-ownership rights (store, publish, print) with no attribution requirement. That rights bundle is the headline, not just the lower number.
Unit economics & gross margin
| Tier | Price | Included | Effective COGS (realistic usage) | Gross margin |
|---|---|---|---|---|
| Indie | $15 | 10,000 | ~$1.70 (typical ~20% quota, ~40% cache hits) | ~89% |
| Studio | $49 | 50,000 | ~$5 to $9 | ~82 to 90% |
| Scale | $129 | 200,000 | ~$20 to $35 | ~73 to 84% |
Honest worst-case note: at the absolute worst case (a customer using 100% of 10,000 Indie analyses, every one a cache miss, every month), COGS is ~$14 against a $15 price: a terrible 7% margin. That case is not realistic (most API customers use a fraction of quota; repeats hit cache), but it means (1) included-request counts must be set so expected margin is healthy, not the theoretical max, and (2) we meter overages (e.g. $1.50 per additional 1,000, a ~10× markup on COGS) so heavy users pay their way. With realistic usage and caching, every tier clears ≥75% gross margin.
Breakeven: fixed costs are ~$6 to $30/mo, so breakeven is a single Indie subscriber. One $15/mo customer covers infrastructure with room to spare. The question is demand, not whether it's cheap to run. It is extremely cheap to run.
6. Competitive Matrix
Honest about the gap| Dimension | NutriForge | Spoonacular | Edamam | Nutritionix |
|---|---|---|---|---|
| Entry paid price | $15/mo | $29 (Cook) | $29 → $299 jump | 4 figures/mo (quote) |
| Free tier | 500/mo, full rights | metered ~150-200 pts/day | few hundred calls/mo | none anymore |
| Store full panel in your DB | Yes, unrestricted | Yes (paid) | No (4 macros, behind pw) | per contract |
| Publish on public sites | Yes, unrestricted | Yes (attribution) | No (behind pw) | per contract |
| Print in cookbooks | Yes, unrestricted | Yes (attribution) | No | per contract |
| Attribution badge required | No | "powered by" expected | Yes, every plan | per contract |
| Micronutrients | Yes (Fe, Ca, K, Zn, Mg, vits) | Yes, broadest (~40) | Yes (28) | basic panel |
| Free-text recipe analysis | Yes (core job) | Yes | Yes (best NLP) | partial, restaurant-tuned |
| Branded / restaurant foods | Weak (the honest gap) | Strong | Moderate | Strongest (their core) |
| Data source | USDA public domain | crowd/scraped + licensed | proprietary | proprietary, restaurant |
Reading it honestly: we win decisively on price, rights, and the free tier. We tie on micros and core recipe analysis. We lose on branded and restaurant foods, and that's a real gap, not a footnote. Edamam reputedly has the best raw NLP; we're betting USDA-grounded matching plus an LLM disambiguator gets close enough on home-cooked recipes, which the validation bar exists to prove or disprove before we charge. The branded gap is the incumbents' genuine moat.
7. MVP Scope + Phased Roadmap
Phase 0 → 1 → 2Phase 0 Build the engine, clear the gate (no selling yet). Ingest USDA FDC into D1, build the food-search index and density table, build the four engine pieces with DeepSeek on the parse/match step, run against RecipeMemoir's recipes using the Spoonacular backfill as the gold standard, and validate against the section-4 bar (iterate mostly on gram conversion until all five rows pass). Dogfood: RecipeMemoir switches its computed-nutrition path from Spoonacular to NutriForge and retires the $29/mo Spoonacular fee. First real win, first reference customer.
Phase 1 Public API + dev portal + billing. REST API with keys, rate limiting, R2 response caching, usage metering. Self-serve dev portal (sign up, get a key, see usage, read docs, upgrade). Stripe billing wired to the tiers. Resend for transactional email. Public docs with the rights story front and center. Launch Free + Indie + Studio.
Phase 2 Branded foods, batch, SDKs. Improve matching against USDA Branded Foods (barcode/UPC lookup first, the easier subset). Batch endpoint for backfills. Official SDKs (JS/TS, then Python) and a WordPress/CMS plugin to chase the food-blogger segment. Scale + Enterprise tiers, white-label.
8. Tech Stack
Cloudflare-aligned- Compute / API: Cloudflare Workers (account
6c39c9d7bff1afc0eee21b0a080d98fe). - Data: D1 (
nutriforge-db) for USDA lookup tables, accounts, keys, usage. R2 for the response cache and bulk USDA artifacts. - LLM: DeepSeek via OpenRouter (
deepseek/deepseek-chat) with prompt caching on the stable block; DeepSeek-direct as a cost-down later. - Billing: Stripe (needs Annette's account; metered/subscription products).
- Email: Resend (transactional).
- Dev portal / docs: static site on Cloudflare Pages, production branch
main, same pattern as her other sites.
9. Risks & Mitigations
The weak parts, named- Accuracy vs incumbents. Risk: "close but not as good," and devs stick with the known name. Mitigation: the validation bar is a hard gate; we publish our accuracy methodology as a trust asset; we compete on rights + price where we're provably close, not on a "most accurate" claim we can't back.
- The branded-food gap (biggest product risk). Risk: a meaningful slice of demand is "what's in this packaged/restaurant product," and USDA Branded matching is hard, so we lose those buyers. Mitigation: don't pretend otherwise; target the recipe-analysis and home-cooked segment where USDA is strong, lead with rights, treat branded as a phase-2 climb. Honest take: this gap caps our addressable market; it doesn't close it.
- LLM dependency / cost drift. Risk: DeepSeek prices rise or the model degrades. Mitigation: the LLM only parses and disambiguates (never sources numbers), so it's swappable; the cost model survives a 3 to 5× price increase and still clears 75% margin; a classical-parser fallback for clean lines reduces LLM calls.
- Support burden. Risk: a paid API means SLAs, "why is this number wrong" tickets, billing disputes: real human time for one person. Mitigation: confidence scores + flagged low-confidence lines set expectations honestly; thorough self-serve docs; async email support only, no SLA promises below Enterprise.
"Is the market big enough, and is undercutting-on-price a trap?" Honest take: the nutrition-API market is real but not huge, and it's dominated by incumbents with brand trust and the branded-food moat. Undercutting on price alone IS a trap: a bigger, better-funded incumbent can match a price cut and outlast a solo operator, and "cheapest" attracts the least loyal customers. The durable differentiator is rights, not price: "store it, publish it, print it, own it, no attribution" is a structural advantage rooted in our public-domain data source that Spoonacular and Edamam cannot copy without changing their own data licensing. Price gets attention; rights and the developer experience are what we defend on. If we only win on price, we lose; if we win on rights, price is just the hook.
10. Open Decisions
For Annette- 1 Name and domain. "NutriForge" is provisional. Alternatives: MacroForge, ForkFuel, PlateMacros, NutriCast. Action: run a domain-availability + trademark check on the shortlist before any branding work. (Do not commission a logo or buy a domain until you pick.)
- 2 Pricing finalization. The tiers are a proposal. Included-request counts and the overage rate ($/1,000 over quota) need a final pass against expected (not worst-case) usage; decide whether to meter overages or hard-cap. A lifetime/founding-member option for early adopters is worth considering.
- 3 Self-host an open parser vs pay-per-call LLM. Pay-per-call DeepSeek is cheapest to start and zero-ops. At high volume a self-hosted open parser (or fine-tuned small model) could cut LLM cost to near-zero and remove the dependency, at the cost of ops burden. Decide at a volume threshold, not now.
- 4 Build-it-now vs wait-for-the-Spoonacular-benchmark-data. The validation bar depends on RecipeMemoir's Spoonacular backfill as the gold standard. Option A: wait for that backfill, then build against ready-made gold data (lower risk). Option B: build the engine in parallel now and validate as soon as it lands (faster, some rework risk). Leaning A for the validation phase, but engine scaffolding can start in parallel.
Provisional Registry Score
Pending your reviewScored on the 8-criterion ladder (1 low to 5 high, max 40), provisional pending Annette's review:
Why these numbers: real API revenue but a smallish market (Revenue 4); unlocks RecipeMemoir and gives a reusable engine across her recipe projects (Strategic 4, Reusability 4); removes RecipeMemoir's Spoonacular dependency and cost (Bottleneck 4); less emotional pull than RecipeMemoir itself (Excitement 3); the engine + validation is real work (MVP 3); no deadline (Urgency 2); USDA data and LLM drift need periodic upkeep (Maintenance 3).
Build plan written 2026-06-12 · Income project · Validation bar is a hard ship-to-sell gate · The weakest part of the case is the branded-foods gap and that price-undercutting alone isn't durable; the defensible wedge is data-ownership rights · Private · ← Hub