NutriForge business plan: selling API access (revised)

Working name: NutriForge (provisional). Originally written 2026-06-13. Revised 2026-06-13 after a 4-LLM adversarial diligence panel (x-ai/grok-4.3, openai/gpt-5.5, google/gemini-3.1-pro-preview, anthropic/claude-opus-4.8; raw critiques and synthesis in docs/reviews/). This is the go-to-market and revenue plan: who buys, how we reach them, what we charge, and the concrete sequence to first paying customers and first $1k MRR. It builds on the locked thesis, cost model, and pricing in docs/BUILD-PLAN.md, and now hardens or corrects the parts the panel tore apart.

Every external price below is sourced inline to the provider's own current page (or a flagged secondary source). Provider pricing changes; confirm at signup before committing real money. Any forward-looking number (subscribers, MRR) is a clearly-labeled estimate, not a measured fact. We don't have customers yet, so the financial model is a set of scenarios under stated assumptions, nothing more.

What changed in this revision and why (changelog)

A four-model investor panel reviewed the original plan adversarially. Consensus criticisms (3-4 reviewers agreeing) drove these changes. Full detail in docs/reviews/SYNTHESIS.md.

1. Fixed a real pricing error and rebuilt the unit economics. The panel caught that the old "$1.50/1,000 overage = ~10x markup" claim was a math error (it's ~$1.40 COGS/1,000, so a ~7% margin, and negative through a marketplace cut). Indie's included quota is cut from 10,000 to 2,000, overage is raised to $6/1,000, and every tier now shows worst-case AND expected margin with Stripe/marketplace fees included (section 7). [C1]
2. Added free-tier COGS to the model and gated the free tier. The old model treated free users as cost-free; the panel computed up to ~$1,050-$2,800/mo in omitted free COGS. Free quota cut to 300/mo, verified-email + fingerprinting added, and a meaningful paid-only benefit (commercial-use terms + batch) introduced so the free tier can't cannibalize Indie (sections 6, 7). [C2]
3. Reframed the moat. Dropped the false "incumbents can't copy this" claim. The honest position: it's an awareness gap defended by depth in a segment too small for incumbents to defend, plus a modeled competitive-response playbook (sections 2, 4, 11). [C3]
4. Scoped the rights claim and de-risked it legally. The unrestricted-rights promise is now scoped to Foundation + SR Legacy + FNDDS generic data only, Branded explicitly excluded, reframed as "you own your results, we claim no copyright on the output," with a paid legal-read line-item and ToS disclaimers (sections 4, 6, 11, 14). [C4]
5. Rebuilt validation around ground truth. Added a hand-calculated USDA benchmark as the primary accuracy bar (Spoonacular demoted to one comparator), per-category accuracy reporting, and a tightened user-facing accuracy story (section 8, and BUILD-PLAN section 4). [C5]
6. Quantified the funnel and gated GTM behind a single-channel proof. Added explicit funnel math, a "prove one channel with a kill metric before building the full surface" sprint, and demoted the over-stuffed 90-day plan (sections 9, 10, 13). [C6, M3]
7. Treated the branded gap as a conversion risk, not just a market cap, with a dumb pass-through and front-loaded onboarding; added the backfill-and-cancel churn dynamic (sections 11, 9). [S1, S2]
8. Led with the honest ceiling and added every missing standard section: opportunity-cost/time budget, validation time-box and kill rules, support-as-COGS, team/ops & bus-factor, SLAs, DPA/security, data-refresh cadence, instrumentation, exit/optionality (sections 1, 10, 14, 15). Dropped lifetime deals; rebuilt sizing bottom-up (sections 3, 7). [S3, S5, C7, M4]

1. Executive summary (with the honest ceiling up front)

NutriForge is a developer-facing nutrition-analysis API: you POST a recipe's free-text ingredient list, and you get back per-serving macros and micros. It's built on public-domain USDA FoodData Central data, which lets customers do the thing the leading incumbent (Edamam) forbids: store the computed nutrition, publish it on public websites, and print it in cookbooks, with no caching limits and no attribution badge. The pitch in one sentence: own your nutrition results, store them, publish them, print them, at a fraction of Edamam's price.

The honest ceiling, stated first (the panel's loudest note). This is a lifestyle micro-SaaS, not a venture-scale business. Under the realistic (Base) scenario it reaches roughly $1,500-$2,000 MRR after about 24 months of part-time solo effort (section 10). The most likely failure mode isn't a blowup, it's a slow, profitable-but-trivial trickle that quietly eats 18 months of Annette's best time for sub-$2k/mo. So the plan carries an explicit go/no-go kill rule (section 13): if we don't have 3 paying customers by month 6 and a working channel, we stop, fold the engine back into RecipeMemoir as a private cost-saver, and move on. The reason to do it anyway: the downside is bounded (near-zero cash cost, breakeven at one real customer), the engine pays for itself the day RecipeMemoir retires its Spoonacular fee, and there's genuine optionality (a WordPress plugin, a white-label deal, or an acquihire of the rights-positioning and customer list). We do it eyes-open, time-boxed, as customer-zero-funded experiment, not as a bet-the-year.

The wedge, stated honestly. Price gets the click; the rights story attracts the stickier, less price-shoppy customer. But the rights advantage is an awareness gap, not an uncopyable structural moat (section 4): an incumbent could carve out a USDA-only "store your results" tier. Our defense is to win the segment too small for them to bother defending (recipe bloggers and cookbook/print tooling), with non-copyable depth (best-in-class gram conversion, an embedded WordPress publishing workflow), rather than announcing a price-and-rights undercut they can match.

We sell through self-serve developer channels (a RapidAPI listing for discovery and billing, a gated free tier, copy-paste docs, SEO/GEO comparison pages, and the RecipeMemoir case study), but only after a one-channel proof clears its kill metric (section 13). RecipeMemoir is customer zero and the flagship case study. This plan is mostly about the one thing that actually decides the outcome: can we find and convert enough developers, cheaply and repeatably, before the experiment's time budget runs out.

2. The problem and the wedge

The problem developers have

If you're building anything that touches recipes, meal plans, or food logging, you eventually need to turn "2 lbs boneless chicken breast, 2 cloves garlic, season to taste" into real per-serving nutrition. Doing it yourself means parsing messy lines, matching each to a food database, converting portions to grams (the genuinely hard part), pulling per-100g panels, scaling, summing, and dividing by servings. Most developers don't want to own that pipeline, so they reach for an API.

Then they hit the second problem, the one nobody warns them about: the leading recipe-analysis API (Edamam) won't let them keep the answer. Edamam's own terms say the returned 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 live "behind a password" for the human who initiated the request (Edamam Nutrition Analysis API). Attribution is mandatory on every plan, and "not providing attribution is considered breach of contract and is followed by immediate service suspension" (Edamam). So a food blogger auto-generating a nutrition label and publishing it on a public page, or a cookbook tool printing nutrition in a book, is either in breach or buying a custom enterprise license. Spoonacular is friendlier here (it permits storage and public display on paid plans, with "powered by" attribution expected), so our rights advantage over Spoonacular is narrower: lower price and no attribution badge. Our rights advantage over Edamam is decisive. We say exactly that, rather than overclaiming a universal moat (the panel flagged the matrix for overstating the Spoonacular gap).

The wedge (and its honest limits)

NutriForge is built on USDA FoodData Central, which is US-government public-domain data with no storage, display, or attribution restrictions on the generic-ingredient datasets (USDA FDC). That lets us grant rights Edamam can't:

• Data-ownership rights (the differentiator). Store the full computed panel in your own database. Publish it on public sites. Print it in cookbooks. No caching limits, no attribution badge. Scoped to generic-ingredient analyses (Foundation, SR Legacy, FNDDS); we explicitly do not extend the unrestricted-rights grant to USDA Branded Foods entries, because those carry manufacturer trademarks and label-data nuances (section 4, 11). Reframed legally as: we claim no copyright over the analysis output; you own your results.
• Price (the hook). We undercut Edamam's entry-to-next-tier jump and sit at or below Spoonacular's entry plan, because our COGS is structurally low (section 7).

The order matters, and so does the honesty. Price gets attention; rights attract the right customer. But "no incumbent can copy this" is false, and we no longer claim it. Any incumbent could publish a USDA-only "store and publish your results" tier sourced from the same public-domain data, keeping their proprietary branded data restricted. What they're unlikely to do is build deep, polished tooling for a segment too small to move their numbers (the recipe-blogger and cookbook/print niche). That's where we win, by depth and focus, not by a moat that can't be crossed. The competitive-response playbook in section 11 takes this seriously.

Why now

• Edamam tightened its caching and attribution terms and Nutritionix pulled its public free tier and went partner-only/quote-based (Spike API roundup 2026). There's a widening gap between "I just want to analyze a recipe and own the result" and what those two will sell a solo developer.
• A cheap, capable LLM makes the hard parts solvable at near-zero marginal cost. The ingredient-parse and food-match steps run on a model like DeepSeek for a fraction of a cent per recipe, which is what makes the price wedge possible without bleeding margin.
• The "own your data" stance is in the air. Data portability and anti-lock-in resonate with developers right now, not just price.

3. Market and sizing (bottom-up, with the inflation corrected)

Two honesty notes first. (1) The nutrition/recipe-API market is real but niche, and public figures for this exact slice are thin. All sizing is labeled estimates from stated assumptions, not market research. (2) The panel correctly flagged that the old sizing was inflated in the wrong segment: nutrition-API spend concentrates in enterprise/branded/restaurant/fitness buyers, which are exactly the segments we serve worst. This version subtracts that slice instead of counting it.

Who buys nutrition APIs today

Developers building: recipe and meal-planning apps, food blogs and recipe-CMS plugins, fitness/macro-tracking apps, diabetes/CGM and health startups, and (the branded/restaurant slice we're weak on) calorie-counting and menu apps. FatSecret reports 50,000+ developers and 700M+ API calls/month (FatSecret Platform API), but the panel's correction stands: that's overwhelmingly free hobbyists, not paying accounts. It tells us the developer population touching food data is in the tens of thousands; it does not tell us the paying base is.

TAM: corrected bottom-up estimate

"Annual spend by developers on third-party food/nutrition analysis APIs worldwide." Transparent bottom-up, with the wrong-segment correction:

• Assume 15,000 to 40,000 paying developer accounts globally (down from the old 30k-80k, discounting FatSecret's number as mostly free; assumption, not measured).
• Assume blended paid spend of ~$40 to $120/mo (most on entry tiers, a few enterprise contracts pulling the average up; assumption).
• Implied TAM ~$7M to $58M/year. Working midpoint ~$20M to $30M/year, treated as soft.
• Now subtract the branded/restaurant-dependent slice we can't serve well. If roughly half of paid spend is branded/restaurant/enterprise-concentrated (the panel's point), the TAM we can actually compete for is ~$10M to $15M/year.

A niche, not a gold rush. Plenty for a one-person near-zero-fixed-cost business; far too small to attract a funded swarm (that smallness is itself a mild defense, section 11).

SAM: estimate

We serve the recipe-analysis / home-cooked segment where USDA generic data is strong, and within it the buyers who care about owning/publishing/printing results. Assume that slice is ~20% to 35% of the competable TAM. SAM ~$2M to $5M/year. (Assumption derived from the corrected TAM.) This is deliberately smaller and more honest than the prior $10M-$24M.

SOM: what we can realistically get (demand-gated)

Solo-operated, self-serve, no sales team, no assumed ad budget. Realistic obtainable share in 12-24 months is small and entirely gated by distribution:

• Conservative (Lean) 24-month SOM: ~$5k to $20k ARR.
• Base 24-month SOM: ~$18k to $30k ARR.
• Upside 24-month SOM: ~$50k to $90k ARR (requires a breakout content/launch moment or 1-2 small white-label deals).

These map to section 10's scenarios, which now carry explicit funnel and churn math. The single biggest swing factor is distribution, not unit economics.

4. Competitive analysis (with the matrix corrected and the moat honestly framed)

The product-level matrix lives in docs/BUILD-PLAN.md section 6. Here it is with data-ownership rights pulled forward, the Spoonacular overclaim corrected, and a developer-experience (DX) read.

How to read it honestly. We win decisively over Edamam on rights, price, free tier, and self-serve DX. Over Spoonacular the rights win is narrower (Spoonacular already permits paid storage and public display): our real edge vs Spoonacular is no attribution badge + lower price + simpler subscription vs their fiddly points. We tie on micros and core recipe analysis. We lose on branded and restaurant foods, and that's a conversion risk, not just a market-size footnote (section 11). USDA-direct is "free" but isn't a competitor in the same sense: it's a raw database with no parsing, matching, or gram-conversion, which is the work developers pay us to do.

The moat, honestly: an awareness gap defended by depth

The panel unanimously rejected "no incumbent can match this without re-licensing their whole business." They're right. Spoonacular or Edamam could publish a USDA-only "store and publish your results" tier sourced from the same public-domain generic data, keeping their proprietary branded data restricted, without re-licensing anything. They have the parsing, the brand, the distribution, and the developer base to do it in weeks. So our advantage today is mostly that they haven't bothered to package the rights story for a segment too small to move their numbers. That's an awareness gap, and a loud "Show HN: we undercut you on price and rights" launch is exactly what would prompt them to close it.

Our actual defense is therefore depth and focus, not impossibility:

• Win the segment too small to defend. Recipe bloggers and cookbook/print tooling are a niche an incumbent won't build polished, embedded workflow tooling for. We will.
• Build non-copyable depth, not a price claim. Best-in-class gram conversion, a WordPress nutrition-label plugin embedded in bloggers' publishing flow, print/cookbook export. Those are workflow lock-in an incumbent won't replicate for a tiny segment.
• Go deep before going loud. Earn the niche quietly first (section 13), so that if an incumbent reacts, we already have the embedded workflow and the relationships, not just a slogan they can copy.

The competitive-response playbook (section 11) models five concrete incumbent moves and our counter to each.

5. Ideal customer profiles (ranked)

Ranked by fit and reachability. The big change from the prior version: ICP-1 (bloggers) requires a product, not just an API (the panel's point that bloggers buy WordPress plugins, not raw APIs), so the WordPress plugin is now a first-class workstream, not a day-61 afterthought.

ICP 1: Recipe bloggers and food-site CMS plugins (best fit, but needs the plugin)

• Pain: They publish nutrition labels on public recipe pages. Edamam's "behind a password, human-initiated, attribution-mandatory" terms are openly hostile to exactly this.
• Why they'd switch: "Auto-generate a nutrition label, publish it on your page, no badge, you own it." But a blogger won't integrate a raw API. The real product for them is a WordPress/recipe-card plugin that does it in one click. We treat that plugin as core to serving ICP-1, not optional.
• Willingness to pay: Moderate but sticky once embedded in the publishing flow.
• Why ranked #1: Cleanest, most defensible win, reachable via content/SEO and the WordPress plugin directory at low cost. The defensibility is the embedded workflow.

ICP 2: Indie / solo developers / no-code makers (highest volume)

• Pain: Want to analyze a recipe and move on; incumbent pricing/terms feel heavy.
• Why they'd switch: Gated free tier, copy-paste quickstart, $15 entry, they keep their data.
• Willingness to pay: Low per account, huge in count, cheap to acquire (PLG). Many stay free; a fraction convert. This is the funnel's wide top.
• Why ranked #2: Volume and reachability via search, Indie Hackers, dev.to, r/webdev, the marketplace.

ICP 3: Meal-planning apps (strong fit, higher value)

• Pain: Analyze user/imported recipes, display in-app and on public share pages.
• Why they'd switch: Full-panel storage rights, predictable subscription vs fiddly points, micros included.
• Willingness to pay: Higher (Studio/Scale), volume-sensitive. Caveat (panel): they'll ask the bus-factor question (section 11/15); a solo operator with no SLA below Enterprise is a hard sell here until we have a credibility answer.
• Why ranked #3: Good fit and revenue, but longer evaluation and the bus-factor objection.

ICP 4: Fitness / macro-tracking apps (volume, price-sensitive, churn-prone)

• Pain: Per-serving macros at scale; cost-per-call decides.
• Why they'd switch: Aggressive volume pricing + they keep their data.
• Willingness to pay: Medium, very price-sensitive, least loyal segment (the panel's churn warning). They track macros to the gram, so a 20% protein error gets noticed and complained about loudly. Win them on rights + reliability, not price alone, and only after the accuracy story is tight (section 8).
• Why ranked #4: Revenue per account is fine but it's the churn-risk segment.

ICP 5: Cookbook / print / POD tooling (small, perfect-fit, defensible)

• Pain: Need print rights for nutrition in physical books; Edamam doesn't grant them on standard tiers.
• Why they'd switch: We grant print rights explicitly. RecipeMemoir's own KDP cookbook export is the proof.
• Willingness to pay: Moderate, low volume.
• Why ranked #5: Tiny market, near-zero competition, and the print/cookbook workflow is exactly the non-copyable depth an incumbent won't build.

ICP 6: CGM / diabetes / health startups (high value, longer sell, needs DPA)

• Pain: Nutrition for logged foods; some need branded/packaged coverage we're weak on.
• Why they'd switch: Strong on recipe/home-cooked analysis and on owning data for record-keeping; weak on branded SKUs.
• Willingness to pay: High, but they demand a DPA, a security posture, and bus-factor comfort (section 15) before they integrate. Partial fit because of the branded gap.
• Why ranked #6: Real money, longer cycle, a fit caveat. Pursue opportunistically.

ICP 7: Ghost-kitchen / menu / restaurant tools (weakest fit, skip)

• They live in branded/restaurant food, our honest gap. Don't target until the branded pass-through (section 11) proves out.

Targeting order: lead with ICP 1 (via the plugin) and ICP 2 (cleanest, cheapest, product-led); expand into ICP 3, 5; treat ICP 4 and 6 as careful/opportunistic; skip ICP 7.

6. Offering and packaging

Tiers and rights packaged as a headline feature, not fine print. The rights bundle is gated only by the generic-data scope and the commercial-use line, not held hostage by tier.

Two deliberate changes from the panel. (1) Free is now "evaluation/personal use only" for commercial rights: you can try it, build a personal site, prototype, but commercial use requires a paid tier. This gives the free tier a real conversion trigger beyond raw volume, so it stops cannibalizing Indie. (2) Batch is a paid-only benefit (Studio+), not free inside every quota, which also dampens the backfill-and-cancel dynamic (section 9). The store/publish/print rights remain in every tier including free, because that's the position; what's gated is commercial use and volume/convenience.

Rights scope (legal, plain-language). The unrestricted store/publish/print/no-attribution grant covers analyses computed from generic USDA data (Foundation, SR Legacy, FNDDS). For any analysis that touches a USDA Branded Foods entry, the response is flagged branded, and the rights grant is the narrower "we claim no copyright on the computed numbers, but brand names and trademarks in the source are not ours to license, use at your own discretion." This scoping is the legal fix from section 11/14.

Enterprise / white-label

Custom volume pricing, an SLA, a named contact, white-label, a DPA, and a contractual restatement of the scoped rights. Also the home for self-host (below).

Batch + self-host

• Batch endpoint (Studio and up): analyze many recipes in one call (e.g. RecipeMemoir's 1,741-recipe load). Priced as a paid-tier benefit.
• Self-host / on-prem (Enterprise, phase-2+): for buyers who can't send recipe data to a third party (some health/clinical buyers), license the engine to run in their environment for an annual fee plus a USDA-refresh subscription. Clean to offer precisely because the data is public domain.

7. Pricing strategy and unit economics (rebuilt; the broken parts fixed)

The full COGS math is in docs/BUILD-PLAN.md section 5. This section incorporates the panel's pricing corrections directly.

The corrections the panel forced

• The old overage rate was a math error. $1.50/1,000 vs ~$1.40 COGS/1,000 is a ~7% margin, and negative through a marketplace cut, not the claimed "10x markup." Fixed: overage is now $6/1,000 (a ~4x+ markup on the conservative cache-miss COGS even after a marketplace cut), $5/1,000 at Scale.
• The old $15/10,000 Indie tier was structurally unsafe. Worst case ($14 COGS on $15, before Stripe/RapidAPI fees) is break-even-to-negative. Fixed: Indie included quota cut from 10,000 to 2,000. Worst-case COGS is now ~$2.80, leaving a safe margin even through a marketplace cut.
• Free-tier COGS is now in the model (it was omitted). At 300/mo and realistic utilization it's small but real, and section 10's scenarios subtract it.

Tier margins (worst-case AND expected, fees included)

Conservative cache-miss COGS ~$0.0014/analysis; cache-hit COGS ~$0.00003. "Expected" assumes ~20% of quota used and ~40% cache hits (an assumption to be measured, section 8, not a load-bearing fact). Direct = Stripe (~2.9% + $0.30). Marketplace = assume ~20% RapidAPI cut (confirm at listing).

Reading it honestly. At expected usage every paid tier is healthy. The worst case still bites at Studio/Scale if a customer maxes a huge quota on all cache misses, which is exactly why overage is metered at $6/1,000 (it engages before a heavy user can erode the tier) and why quotas were cut. Heavy users pay their way; they don't get subsidized compute. Breakeven is still one Indie subscriber against the ~$6-$30/mo fixed floor, but see the support-time caveat below: breakeven on cash is not breakeven on time.

Free tier: acquisition engine, now gated against abuse

300 analyses/mo, verified email required, device/IP fingerprinting, commercial use disallowed (eval/personal only). The gating is the panel's fix for trivial multi-accounting. The free tier's job is to get a working integration into a developer's codebase; commercial use is the upgrade trigger, alongside volume and batch.

Support time is a real COGS (the hidden line)

The panel was blunt: a single Studio customer's "your API gave my diabetic users wrong carbs" thread can consume more than $49 of human time. We budget support explicitly: confidence scores + flagged lines deflect a class of tickets, docs deflect another, async-email-only (no SLA below Enterprise) caps response obligation, and honest acquisition (not selling to the branded-food buyer) prevents a whole category of disappointed tickets. We instrument tickets/customer/month and treat it as a margin input, not free.

Annual discount, no lifetime deals

~2 months free on annual prepay (Indie $150/yr). Lifetime/founding-member deals are dropped (panel: they trade away the only asset, MRR, for "proof" that a benchmark page delivers better).

8. Validation and the accuracy story (rebuilt around ground truth)

The panel's sharpest methodological hit: "close to Spoonacular" proves nothing, because Spoonacular is crowd/scraped and the plan itself calls it "not ground truth." The fix changes both the gate and the sellable claim.

The new validation methodology (also reflected in BUILD-PLAN section 4)

1. Primary bar: hand-calculated USDA ground truth. Hand-compute exact per-serving macros for ~100 recipes spanning clean lines, messy lines, volume measures, cooked-vs-raw ambiguity, and sodium/sugar-heavy cases, straight from USDA per-100g panels and FNDDS portions. NutriForge's accuracy is measured against this, not against a competitor. The sellable claim becomes "~X% accurate to raw USDA math," which is a real claim, not "kinda close to Spoonacular."
2. Spoonacular as one comparator, not the answer key. Where the RecipeMemoir backfill provides Spoonacular outputs, we report agreement as a secondary signal and triage disagreements (sometimes USDA generic data is closer to truth than Spoonacular's sourcing).
3. Per-category accuracy reporting. Publish accuracy broken out by recipe type (clean / messy / branded / volume-measure / cooked-raw / high-sodium-sugar), so buyers see exactly which kinds of recipes are reliable and which carry caveats. This is the trust asset.
4. Confidence calibration. Show that our confidence scores actually track error (a flagged-low-confidence line is genuinely more likely to be wrong), so callers can trust the flags.
5. Tighter user-facing story on the macros that matter. Calories and the big-three macros get the tightest internal budget because that's what users notice; the published benchmark reports median and 90th-percentile error per nutrient, not just pass/fail.

Gram conversion: the brittle core, now time-boxed

Piece 3(b) (portion-to-grams) carries the most accuracy risk. The panel's point: there's no contingency if it won't converge. Fix: the validation gate is time-boxed (section 13). If gram conversion can't clear the ground-truth bar within a set number of weeks, that's a kill signal, and the engine still has value as a private RecipeMemoir cost-saver even if it never clears the external-sale bar. A classical regex + FNDDS-lookup fallback for clean lines (a BUILD-PLAN open decision) reduces LLM dependency and gives a measurable accuracy delta.

9. Go-to-market and the sales motion (channel-proof gated)

The panel's verdict on the old GTM: "a list of places to post," not a repeatable channel, with the entire demand engine unquantified. The fix is to quantify the funnel and prove one channel before building the full surface.

Funnel math (the numbers the old plan was missing)

For a self-serve developer API, a realistic funnel looks like:

• Organic/marketplace sessions -> signup ~2-5% (assumption; instrument it).
• Signup -> activation (a successful authenticated in-code call) ~25-40% if docs are good (assumption; instrument it).
• Activation -> paid ~1-3% for a no-card developer free tier (assumption; the panel flagged the old plan's implicit ~4% as optimistic; we model 1-2% in Base).
• Implication: to net ~45 paying Indie-equivalents, we likely need on the order of 2,500-6,000 free signups, which means tens of thousands of qualified sessions over 18-24 months. That is the real bar SEO/GEO + RapidAPI + the case study must clear. We size content and outreach against that, not against a subscriber table.

The seven channels (unchanged in kind, now honest about timelines)

(a) RapidAPI for cold discovery and billing (handles key, metering, payout). Honest caveat the panel forced: marketplace traffic skews hobbyist, RapidAPI customers are partly RapidAPI's (limited email/marketing access), so a marketplace Indie customer may be worth less than half a direct one in LTV. We list there for discovery, run direct Stripe in parallel from day one for the customers we earn, and treat RapidAPI as one channel, not the business. (b) Product-led growth: gated free tier, instant key, copy-paste quickstarts (curl/JS/Python), a live "try it" box, official SDKs (JS/TS first). (c) Content / SEO + GEO, with the honest timeline: SEO compounds over 6-18 months against incumbents with high domain authority (and roundup blogs like spikeapi.com contest the same keywords). This is a slow channel, not a 90-day one. We still build the comparison/alternative pages (lead with the rights table) and tutorials, run them through the geo-optimizer skill, but we do not assume they produce signups inside 90 days. (d) The data-ownership angle as the lead message ("the nutrition API you actually own the output of"), price second. (e) RecipeMemoir as the flagship case study (1,741 recipes, retired Spoonacular fee, published nutrition on public sites and in KDP cookbooks, all on owned data) and the ground-truth benchmark (section 8) as the accuracy trust asset. (f) Community at launch: Show HN, Indie Hackers (build-in-public, honest branded caveat), dev.to (the engine write-up), Reddit (genuine recommendations with the honest caveat). The panel's caution: Show HN is a 24-hour spike, not a channel, and going loud invites the incumbent response (section 4), so we go deep in the niche first (section 13) and use the loud launch only once the embedded workflow exists. (g) Targeted outbound to ICP 1 and 5: find blogs publishing Edamam-badged nutrition labels, offer a free migration and the plugin; reach WordPress recipe-plugin authors and the print/cookbook tooling niche.

The sales funnel and the churn dynamic the panel surfaced

Discover -> Try (gated free key) -> Activate (a successful in-code call, the key metric, instrumented) -> Convert (commercial-use, volume, or batch trigger) -> Expand -> Retain.

Backfill-and-cancel (the panel's retention warning). For bloggers and cookbook tools, the rights pitch + batch + no lock-in can mean: subscribe one month, batch-analyze everything, cancel, keep the data forever. We address it three ways: (1) batch is Studio+ only (section 6), so a one-month backfill costs a real $49, not $15; (2) ICP-1's stickiness comes from the embedded WordPress workflow (ongoing per-new-recipe analysis in their publishing flow), not from data lock-in; (3) we'll offer a separate one-time backfill price for episodic jobs so the recurring tiers aren't mispriced against backfill behavior. Honest net: some segments are episodic, and we price for that rather than pretending the API is sticky-by-construction for everyone.

10. Operating / financial model (12-24 months, 3 scenarios, now with funnel + churn)

Everything here is an estimate under labeled assumptions. We have zero customers today. Costs are grounded in the real COGS/margin model; revenue is assumption-driven. The change from the prior version: free-tier COGS is included, churn is separated from gross adds, and support time is acknowledged.

Shared assumptions:

• Fixed cost floor ~$6 to $30/mo; call it ~$20/mo.
• Blended gross margin on paid usage ~85% at expected utilization (section 7).
• Free-tier COGS is now a line: at realistic ~15-20% utilization of the 300/mo free quota, ~$0.06-$0.08 per free account per month (subtracted below).
• Marketplace cut ~20% on marketplace-sourced revenue; direct-billed customers have none (confirm RapidAPI's rate at listing).
• Monthly logo churn ~3-5% on Indie (price-sensitive), lower on Studio/Scale (assumption); the subscriber snapshots below are net of churn, so gross adds are higher than the deltas suggest.
• Tier mix skews Indie/Studio early; Scale/Enterprise arrive later and lumpier.

Lean scenario (distribution stays hard, slow word-of-mouth only)

• Month-24 ARR ~$5.5k. Pays for itself many times over; a side-income trickle, not a living. The "we built it, it works, distribution never caught fire" outcome, and the one that triggers the section-13 kill rule.

Base scenario (content compounds slowly, a couple of community posts land, the plugin gets some bloggers)

• Crosses ~$1k MRR around month 16-20. Month-24 ARR ~$20.5k. A real but modest micro-SaaS income stream. This is the realistic target, and the panel's honest read stands: ~$1,700 MRR after two years of part-time effort is a hobby that pays for itself, not a business. Worth doing only because the downside is bounded and the engine already pays for itself via RecipeMemoir (section 1).

Upside scenario (a breakout launch + the WordPress plugin catches on + 1-2 small white-label deals)

• Crosses ~$1k MRR around month 9-11. Month-24 ARR ~$60k. Requires a Hacker News / Product Hunt breakout, the plugin catching on with bloggers, or a couple of white-label deals. Possible, not the base case.

Reading the three scenarios. The cost side barely moves; the entire spread is demand. The plan's job is to push from Lean toward Base via the channel-proof sprint (section 13) and the WordPress plugin. The honest framing (section 1) governs: even Base is sub-$2k MRR, so the time budget and kill rule decide whether this is worth continuing past month 6.

11. Risks and mitigations (expanded, with the competitive-response playbook)

• The branded-food gap is a CONVERSION risk, not just a market cap (panel upgrade). Branded items appear inside "home-cooked" recipes constantly ("1 can Campbell's cream of mushroom," "1 packet Hidden Valley ranch," "1 box Jell-O," "Oreo crust"). If the API maps these to bad generic substitutes, the developer's end-user sees a broken app and churns. "Be honest in the docs" isn't enough, because disappointed users still sign up, test 5 recipes, and leave. Mitigations: (1) a "dumb" Branded pass-through: exact-string lookup against USDA Branded so the API returns something low-confidence rather than failing; (2) front-load the limitation in onboarding, not buried in docs, so the right customers self-select before they're disappointed; (3) treat full branded matching as a real phase-2 climb (barcode/UPC first). It caps the addressable market and threatens early retention; we manage both rather than minimizing them.

• The moat is an awareness gap, and a loud launch invites the close (panel). Mitigation: depth-and-focus, not impossibility (section 4): win the small segment with embedded workflow (WordPress plugin, print/cookbook tooling), go deep before going loud, and run the competitive-response playbook below.

  Competitive-response playbook (five concrete incumbent moves + our counter):

  1. Spoonacular/Edamam publish a USDA-only "store your results" tier. Counter: we already own the embedded blogger/print workflow and the relationships; we compete on depth and DX in the niche, and we lean harder on price + no-badge + the plugin. Decision rule: if an incumbent matches rights AND undercuts price, we stop competing on price and retreat to the embedded-workflow segments (ICP 1, 5) where switching cost is the plugin, not the API.
  2. Edamam loosens caching/attribution terms. Counter: our comparison pages shift from "Edamam forbids this" to "Edamam charges $299 for what we include," still a real gap on price and DX.
  3. Incumbent price-matches the entry tier. Counter: we don't chase to zero; rights + plugin + print workflow carry the niche. If we can only win on price, we've already lost (we accept that and pivot to the niche).
  4. FUD on accuracy / "no dietitian validation" / "LLM can hallucinate" / "solo, no SLA." Counter: the ground-truth benchmark (section 8) and published per-category accuracy answer the accuracy FUD directly; the bus-factor answer is the self-host/escrow option (below) for serious buyers.
  5. Incumbent buys attention (comparison ads, sponsors a WordPress recipe plugin, pays food-blogger influencers). Counter: we can't outspend; we out-focus, owning the specific blogger/print niche workflow and the genuine "you own your results" relationship.

• The USDA public-domain rights claim is a customer-facing legal promise, not a footnote (panel, upgraded to a funded task). Bite points: Branded Foods carries manufacturer trademarks/label data and possible third-party-pipeline restrictions; international (EU/UK) database rights can attach to a compiled database even when US facts are public domain, and customers are global; the LLM in the loop can introduce non-USDA content; the density table, if scraped, contaminates the claim; "print in a cookbook" is not an FDA Nutrition Facts label. Mitigations: (1) a real, paid, dataset-by-dataset legal read before the claim becomes marketing (budgeted as a line-item in section 14, not "confirm at signup"); (2) scope the unrestricted grant to Foundation/SR Legacy/FNDDS generic data and explicitly exclude Branded (section 6); (3) reframe the promise as "we claim no copyright on the output; you own your results" rather than "this data is public domain, do anything"; (4) ToS disclaimers: outputs are estimates, not medical advice, not an FDA-compliant food label; (5) build the density table only from public-domain/own-measurement sources.

• Accuracy / validation (panel: "close to Spoonacular proves nothing"). Mitigation: the ground-truth USDA benchmark is now the primary bar (section 8); Spoonacular is one comparator; we publish per-category accuracy and confidence calibration; the user-facing claim is "accurate to raw USDA math," and we never claim "most accurate."

• Distribution is unproven and slow (the real top risk). Mitigation: quantify the funnel before building (section 9), prove one channel with a kill metric (section 13), and accept the 6-18 month SEO timeline rather than assuming 90-day signups.

• Free-tier abuse + bottom-tier margin (panel). Mitigation: gated free tier (verified email, fingerprinting, eval-only commercial), cut quotas, fixed overage math, free-tier COGS in the model (sections 6, 7).

• Backfill-and-cancel churn (panel). Mitigation: batch is Studio+, a one-time backfill price for episodic jobs, and ICP-1 stickiness from the embedded plugin, not data lock-in (section 9).

• Single-developer bus factor (panel: a B2B sales-killer, not just a support risk). A meal-planning or CGM buyer will ask "what happens to our pipeline if you stop?" Mitigations: (1) be honest that ICP 3/6 are gated by this; (2) offer source/self-host escrow on Enterprise (they can run the engine themselves if we disappear, which the public-domain data makes clean); (3) keep the addressable early market on the indie/blogger/print tail where bus-factor matters less, and earn the credibility to move upmarket over time.

• Support load on one person (panel: a real COGS). Mitigation: confidence scores + flagged lines, thorough docs, async-email-only, honest acquisition, and instrumenting tickets/customer as a margin input (section 7, 15).

• Market size (panel: inflated in the wrong segment). Mitigation: the corrected bottom-up sizing (section 3) is smaller and honest; near-zero fixed cost means even Lean is cash-profitable; we size for a solo micro-SaaS, not a venture outcome, and the smallness mildly deters a funded swarm.

12. Milestones and roadmap to first revenue

Each milestone has the metric that matters. Don't advance until the prior gate's metric is met. Note the new channel-proof gate (M3.5) and the kill rule (section 13).

• M0: Engine clears the ground-truth validation bar. Metric: accuracy thresholds pass on the hand-calculated USDA benchmark (section 8). Hard, time-boxed gate: no selling before this, and a kill signal if it won't converge in the time box.
• M1: Dogfood cutover. Metric: RecipeMemoir runs entirely on NutriForge; the $29/mo Spoonacular fee is retired. The engine now pays for itself regardless of external sales. First reference customer + case-study data captured.
• M2: Self-serve infrastructure live. Metric: a developer can sign up (gated), get a key, read docs, make a successful call, and (on paid) be billed, with no human. JS/TS SDK shipped.
• M3: RapidAPI listing live + first SEO/GEO pages published. Metric: listing discoverable, first comparison pages indexed.
• M3.5: Channel proof (NEW). Metric (the kill metric): the section-13 one-channel sprint produces 10 activated users and 3 paid commitments in 60 days. If it fails, that's the go/no-go signal, not a reason to build more surface.
• M4: First 10 free-tier activations. Metric: 10 developers have made a successful in-code call.
• M5: First paying subscriber. Metric: 1 paid conversion (cash breakeven).
• M6: First 10 paying subscribers. Metric: 10 paid accounts, churn-watched (net, not gross).
• M7: ~$1k MRR. Metric: ~$1,000 recurring monthly revenue. The point where it's worth doubling down on content + the WordPress plugin.

Beyond M7: phase-2 product (branded pass-through then real branded matching, batch, the WordPress plugin maturing), the white-label/self-host motion, and continued SEO/GEO compounding.

13. The action plan, the channel-proof sprint, and the kill rule

Sequenced, gated by the validation bar AND a single-channel proof. Standing hard stops apply (spend money, send to humans, irreversible, strategy pivot).

First 30 days: prove the engine and quantify the funnel (no public selling)

1. Quantify the top of the funnel FIRST (the panel's highest-leverage test). One day in keyword tools: pull search volume and difficulty for "Spoonacular alternative," "Edamam alternative," "free USDA nutrition API," "recipe nutrition API." If the math can't plausibly produce the Base scenario's free-signup volume via SEO in ~18 months, the central channel is broken and we need a different acquisition thesis before writing engine code.
2. Run the ground-truth validation bar (section 8), time-boxed. Iterate (mostly gram conversion) until the thresholds pass, or hit the kill signal.
3. Dogfood cutover: RecipeMemoir -> NutriForge; retire the $29/mo Spoonacular fee; capture before/after. This makes the engine pay for itself even if external sales never happen.
4. Pick the name + check domain/trademark (NutriForge / MacroForge / ForkFuel / PlateMacros / NutriCast). Blocks SEO/listing/SDK/branding, so do it early.
5. Commission the paid legal read of the USDA datasets (section 11/14) before any rights claim is published.

Days 31-60: the single-channel proof (don't build the full surface yet)

6. Build only the minimum to test ONE channel. The panel was right that the old 90-day plan compressed a year of surface into a quarter. Pick the most likely channel (ICP-1 bloggers via a minimal WordPress nutrition-label flow + 5 comparison pages + ~100 targeted blogger/plugin-author outreaches).
7. Run the channel-proof sprint with a kill metric: 10 activated users and 3 paid commitments in 60 days. Instrument activation (signup -> first in-code/plugin call).
8. Stand up the minimum storefront (docs/landing with the rights-first hero and live "try it" box, self-serve gated keys, Stripe) only as needed to convert the sprint's users. Ship the JS/TS SDK.

Days 61-90: scale the proven channel, or invoke the kill rule

9. If the sprint cleared its metric: publish on RapidAPI, expand the comparison pages, publish the case study + ground-truth benchmark, mature the WordPress plugin, and then consider the loud launch (Show HN / Indie Hackers / dev.to), knowing it may invite the incumbent response (section 4).
10. If the sprint failed its metric (the kill rule): stop external GTM. Keep NutriForge as a private RecipeMemoir cost-saver (the $29/mo saving is real and permanent), shelve the API business, and redeploy Annette's time to a higher-ceiling project. This is success-as-learning, not failure: bounded downside, a working internal tool, ~$348/yr saved, and a clear answer.

The explicit go/no-go (the panel's most important addition)

• Time budget: treat this as a capped experiment, not an open-ended commitment. Roughly: ~2-3 weeks to validate the engine, ~4-6 weeks for the channel-proof sprint.
• Kill criteria: (a) gram conversion won't clear the ground-truth bar in the time box, OR (b) the channel-proof sprint misses 3 paid commitments by day 60, OR (c) by month 6 there are fewer than 3 paying external customers and no working channel.
• Opportunity cost, named: even the Base case is sub-$2k MRR after 24 months. The decision to continue past month 6 must consciously weigh those hours against a higher-ceiling alternative. The engine pays for itself via RecipeMemoir on day one, so "stop the API business, keep the tool" is a fully acceptable, non-failure outcome.

The one decision Annette owns that unblocks the most: confirm she'll sign up for Stripe and pick the name. The validation bar is the technical gate; Stripe + name is the business gate; the channel-proof sprint is the should-we-even-continue gate.

14. Team, operations, legal, and support posture (new section)

The panel demanded the standard operational sections the original omitted.

• Team / ops & bus factor. Solo-operated (Annette). This caps the early addressable market at the indie/blogger/print tail, where bus-factor matters least. To move upmarket (ICP 3/6) we offer source/self-host escrow on Enterprise so a buyer can run the engine themselves if we disappear, clean to offer because the data is public domain. We state the bus-factor limitation honestly rather than hiding it.
• Support model & SLAs. Async email only below Enterprise; no uptime SLA promised below Enterprise; a public status page from launch. Confidence scores + flagged lines + honest onboarding deflect the bulk of tickets. Support time is tracked as a COGS input (section 7).
• Legal / ToS posture. A paid, dataset-by-dataset legal read (Foundation, SR Legacy, FNDDS, Branded, the density table, LLM-derived output, international database rights) before the rights claim is published as marketing. The rights grant is scoped to generic data (Branded excluded), reframed as "we claim no copyright on the output," and the ToS includes disclaimers (estimates, not medical advice, not an FDA label). This is the single most important pre-launch legal task because the rights claim is the positioning.
• Data-update cadence & versioning. USDA refreshes a few times a year. We re-ingest, re-index, re-validate against the ground-truth benchmark, and version the food data so a stored FDC reference doesn't silently break a customer's app; customers are notified when nutrient values they rely on change materially. This recurring ops time is acknowledged, not free.
• Security / privacy / DPA. Recipe text is mostly innocuous, but the CGM/health ICPs require a DPA, a documented subprocessor list (OpenRouter/DeepSeek, Cloudflare, Stripe, Resend), data-retention and deletion policy, encryption at rest and in transit, hashed API keys, and audit logging. We have a DPA template ready for Enterprise and a plain privacy posture for everyone.

15. Key metrics, instrumentation, and exit/optionality (new section)

• Instrumentation (not just "we instrument this"). From day one: a funnel dashboard tracking sessions -> signup -> activation (first successful in-code/plugin call, the key metric) -> paid -> expansion -> churn, with cohort retention; error telemetry that distinguishes a bad-key failure from a DeepSeek 500; per-nutrient accuracy and confidence-calibration tracking; cache-hit-rate measurement (so the section-7 "~40%" assumption becomes a real number); tickets/customer/month as a support-COGS input. Stack: a lightweight analytics layer in the Worker + SDK, no heavy third-party dependency.
• The metrics that gate decisions: activation rate (if low, the docs/quickstart/plugin are broken), free-to-paid conversion (if below ~1%, the conversion trigger is wrong), net (not gross) churn by segment, and the channel-proof sprint's 10-activations/3-paid metric.
• Exit / optionality (the panel: state it so the time investment is judged correctly). This is primarily a lifestyle cashflow asset and a permanent RecipeMemoir cost-saver. Secondary optionality: (a) the WordPress plugin could become the real product (a blogger tool, not an API); (b) a white-label/self-host deal with a meal-planning or health app; (c) an acquihire of the rights-positioning + customer list by an incumbent who'd rather buy the niche than build it. None of these are the plan; they're the upside tail that, together with the bounded downside, justifies the capped experiment.

Business plan written 2026-06-13, revised 2026-06-13 after a 4-LLM adversarial panel (x-ai/grok-4.3, openai/gpt-5.5, google/gemini-3.1-pro-preview, anthropic/claude-opus-4.8; see docs/reviews/). Income project. Grounded in docs/BUILD-PLAN.md and RecipeMemoir/docs/research/nutrition-api-comparison.md. The wedge is data-ownership rights (an awareness gap defended by depth in a small segment, not an uncopyable structural moat) with price as the hook. Lead GTM is developer-led self-serve discovery, gated behind a single-channel proof with a kill metric. The honest weak spots, named not hidden: the branded-food conversion risk, the price-undercutting trap, the unproven and slow distribution, the legal scope of the rights claim, the single-developer bus factor, and a Base-case ceiling that is sub-$2k MRR after 24 months. The decision to continue past month 6 is gated by an explicit kill rule, because the engine pays for itself via RecipeMemoir on day one regardless. All forward-looking subscriber/MRR figures are labeled estimates under stated assumptions, not measured results.