NutriForge: the plan, out loud

A spoken-word walkthrough of the revised NutriForge business plan. Written to be listened to, not skimmed. Roughly 14 to 18 minutes read aloud.

Okay. Let me walk you through NutriForge the way I'd explain it to a friend over coffee, because the written plan is thorough but it's a lot, and sometimes you just want someone to tell you the story.

Here's the big idea in one breath. If you're a developer building anything that touches food, a recipe app, a meal planner, a food blog, a fitness tracker, you eventually need to turn a messy ingredient list into real nutrition numbers. Something like "two pounds of boneless chicken breast, two cloves of garlic, season to taste" needs to become calories, protein, carbs, fat, and a stack of micronutrients, per serving. And doing that yourself is genuinely annoying. You have to parse each line, match it to a food database, figure out how many grams "two cups chopped onion" actually is, pull the nutrition panel, scale it, add it all up, and divide by servings. Nobody wants to own that pipeline. So they reach for an API.

NutriForge is that API. You send us the ingredient list, we send you back the nutrition. Simple.

But here's the part that makes it interesting, and it's the whole reason this exists. The leading recipe-analysis API, Edamam, won't let you keep the answer. I'm not exaggerating. Their own terms say you can't store the data unless they explicitly permit it. If you pay for caching, you're allowed to keep exactly four numbers, and even those have to sit behind a password, shown only to the human who asked for them. And you have to display their badge, or they'll suspend you for breach of contract. So if you're a food blogger who wants to auto-generate a nutrition label and just publish it on your recipe page, Edamam is openly hostile to that. You're either breaking the rules or buying an expensive enterprise license.

NutriForge says the opposite. Store it, publish it, print it in a cookbook, it's your result, no badge required. And we can say that because we're built on USDA public-domain data, the government's free nutrition database. That's the wedge.

Now, why now? A couple of things lined up. Edamam tightened its terms. Nutritionix pulled its free tier and went quote-only. So there's this widening gap between "I just want to analyze a recipe and own the result" and what the big players will actually sell a solo developer. At the same time, cheap, capable AI models showed up, which means the hard parsing work that used to need expensive custom code now costs a fraction of a penny per recipe. That's what makes our low price possible without bleeding money.

So that's the pitch. And honestly, it's a good pitch. But I had four frontier AI models tear this plan apart as if they were skeptical investors, and I want to tell you the truth about what they found, because the honest version is more useful than the shiny version.

Let me start with the hardest thing they said, because I decided to put it right at the top of the plan instead of hiding it. This is a lifestyle micro-SaaS. It is not a venture-scale business. Under the realistic scenario, the one I actually expect, this gets to maybe fifteen hundred to two thousand dollars a month in recurring revenue after about two years of part-time effort. And the most likely way it fails isn't some dramatic blowup. It's a slow, profitable-but-tiny trickle that quietly eats eighteen months of my best time for not much money.

That's a real risk, and I'm naming it. So the plan has an explicit kill rule. If I don't have three paying customers by month six and a channel that actually works, I stop. I fold the engine back into RecipeMemoir as a private cost-saver and I move on. No drama, no sunk-cost spiral.

Here's why I'm doing it anyway, eyes open. The downside is bounded. It costs almost nothing to run. It breaks even on a single real customer. And the engine pays for itself the day RecipeMemoir, my recipe product, stops paying Spoonacular twenty-nine dollars a month and starts running on NutriForge instead. So even in the worst case, I get a working internal tool and I save myself a subscription. That's not failure. That's a capped experiment with a real floor.

Now let me tell you about the wedge, because the models pushed hard on this and they were right to.

I'd originally written that no incumbent could copy our rights advantage without re-licensing their entire business. And all four reviewers said, flatly, that's wrong. Spoonacular or Edamam could spin up a "store your results" tier sourced from the same free USDA data, keep their proprietary branded data locked down, and erase most of my advantage in a few weeks. They have the parsing, the brand, the distribution, the customer base. So the truth is, my advantage isn't that they can't copy me. It's that they haven't bothered, because the slice I'm chasing, recipe bloggers and cookbook tooling, is too small to move their numbers.

That changes the strategy in an important way. If my edge is just an awareness gap, then walking onto Hacker News and shouting "I undercut the big players on price and rights" is literally the thing that wakes them up. So instead, I go deep before I go loud. I win the small niche quietly, with depth they won't bother to match: the best gram conversion in the business, a WordPress plugin that lives right inside a blogger's publishing flow, print and cookbook export. That's workflow lock-in, and it's not something a giant builds for a tiny segment. I also wrote an actual playbook for what I do if an incumbent reacts, five concrete moves they might make and my counter to each. The honest headline is: if I can only win on price, I've already lost. I win on focus and depth, or not at all.

Let me talk about the money, because the models caught a genuine mistake, and I'd rather tell you than bury it.

My original pricing had a math error. I'd said the overage charge, the fee when someone goes over their quota, was a ten-times markup. It wasn't. When you actually do the arithmetic, it was about a seven percent margin, and through a marketplace's cut it was negative. I was charging less than it cost me. So I fixed it. I raised the overage rate, I cut the entry tier's included volume way down so a heavy user can't quietly cost me money, and now every tier shows both the worst case and the expected case, with payment fees and marketplace fees baked in. At normal usage, every paid tier is healthy. The heavy users hit metered overage and pay their way. No more subsidized compute pretending to be a pricing page.

I also fixed the free tier. I'd been treating free users as if they cost nothing, and the models pointed out that at scale that's fantasy accounting, hundreds or even thousands of dollars a month I hadn't counted. Worse, my free tier was wide open: no card, instant key, full rights. Anyone could spin up twenty throwaway accounts and never pay. So now the free tier requires a verified email, has fingerprinting against abuse, and, this is the key move, it's for evaluation and personal use only. Commercial use requires a paid plan. That gives the free tier a real reason to convert, instead of just being a permanent free ride.

Now, validation. This is where the reviewers were most surgical, and where they probably saved me from embarrassing myself.

My plan was to check NutriForge's accuracy against Spoonacular. But Spoonacular is crowd-sourced and scraped, and I'd literally written in my own plan that it's "not ground truth." So one of the models said, bluntly, using it as your answer key is scientifically bankrupt. If you match Spoonacular, you might just be copying its mistakes. And "we're within fifteen percent of a competitor we ourselves say is unreliable" doesn't reassure a serious buyer at all.

So I rebuilt it. Now the primary test is hand-calculated USDA ground truth. I take about a hundred recipes, the clean ones and the genuinely messy ones, and I compute the exact nutrition by hand from the USDA panels. That becomes the bar. The claim I get to make changes from "kinda close to a competitor" to "accurate to real USDA math," which is a claim a buyer can actually trust. I report accuracy by category too, so people can see exactly which kinds of recipes are reliable and which carry a caveat. And the gram conversion, which is the brittlest part of the whole engine, is now time-boxed. If it won't hit the bar in a set number of weeks, that's a kill signal, not an open-ended slog.

Let me talk about who actually buys this, because the models corrected me here too.

My best-fit customer is the recipe blogger. They publish nutrition labels on public pages, and Edamam's terms are openly hostile to exactly that. But here's the thing the reviewers hammered: bloggers don't buy APIs. They buy WordPress plugins. So if I want the blogger market, the real product isn't the API, it's a one-click plugin that does the nutrition label inside their site. I moved that from a day-sixty afterthought to a first-class part of the plan. The plugin is the product for that segment, and it's also the workflow lock-in that makes them stick.

The second customer is the indie developer who just wants to analyze a recipe and move on. That's the wide top of the funnel, low value each but cheap to reach. Then there are meal-planning apps and fitness apps, more money but more demands, and the fitness crowd especially is price-shoppy and quick to churn, plus they count macros to the gram so they'll notice any error fast. There are cookbook and print tools, a tiny but perfect-fit niche where almost nobody else serves them. And there are health and diabetes startups, real money but a long sales cycle, and they'll want a data-processing agreement and they'll worry about the fact that I'm one person.

That one-person thing, the bus factor, is real, and the reviewers flagged it as a sales-killer, not just a support risk. A serious company won't build their nutrition pipeline on a solo developer who might lose interest. My honest answer is that I focus early on the indie and blogger and print tail, where that matters less, and for the bigger buyers I offer source escrow, so they can run the engine themselves if I ever disappear. That's clean to offer precisely because the data is public domain.

There's one more thing the reviewers caught that I love, because it's counterintuitive. My rights pitch can actually hurt retention. Think about it. If a blogger can store and keep their data forever, they can subscribe for one month, batch-analyze their whole back catalog, cancel, and walk away with everything. The very thing I'm selling makes leaving easy. So I made batch a paid-tier-only feature, I'll offer a separate one-time backfill price for those episodic jobs, and I lean on the plugin for ongoing stickiness instead of pretending the API locks people in. Honest pricing for honest behavior.

And the legal piece. My whole pitch is a promise to customers: you own this, publish it freely. The reviewers said, correctly, that's a legal promise, not a marketing line, and it's not as airtight as I'd assumed. The USDA branded-foods data has manufacturer trademarks in it. International database rights are a thing even when the US facts are public domain. And the AI in the loop can introduce content that isn't strictly USDA. So before I ever publish that promise, I'm paying for a real legal read, dataset by dataset. I'm scoping the "own it freely" grant to the generic ingredient data and explicitly excluding branded entries. And I'm reframing it as "we claim no copyright on your results," which puts the promise on solid ground.

So where does that leave us? Let me bring it home.

The plan now leads with the honest ceiling, fixes the pricing math, gates the free tier, reframes the moat as focus rather than impossibility, scopes the legal claim, rebuilds validation around real ground truth, quantifies the funnel instead of hand-waving it, treats the branded-food gap as a thing that can make an app look broken rather than a footnote, and adds all the boring-but-necessary sections an investor would demand: support costs, security, data refresh, the metrics I'll actually track, and what the exit even looks like.

And the path to first revenue is deliberately small. First, I quantify the funnel before I write a line of engine code, one day in keyword tools to see if the search demand is even there. Then I prove the engine against ground truth, time-boxed. Then RecipeMemoir cuts over and the engine starts paying for itself immediately. Then I run a single-channel proof: a minimal blogger plugin, a handful of comparison pages, about a hundred targeted outreaches, with a hard metric. Ten activated users and three paid commitments in sixty days. If I clear it, I scale that one proven channel. If I don't, I invoke the kill rule, keep the tool for RecipeMemoir, and spend my time somewhere with a higher ceiling.

That's the whole thing. It's a clever insight, a genuinely useful tool, a bounded bet, and an honest story about a modest ceiling. I'd rather build it that way, with my eyes open and a kill switch in my hand, than talk myself into a fantasy. And the best part is, on day one, win or lose the API business, I stop paying Spoonacular and I've got an engine I own. That floor is what makes the whole experiment worth running.

So that's NutriForge. Small, sharp, honest, and cheap to find out. Let's go see if the developers show up.