[{"data":1,"prerenderedAt":395},["ShallowReactive",2],{"blog-\u002Fblog\u002Fai-product-unit-economics":3,"blog-surround-\u002Fblog\u002Fai-product-unit-economics":373,"blog-related-\u002Fblog\u002Fai-product-unit-economics":382},{"id":4,"title":5,"audience":6,"body":10,"cluster":337,"contentRole":338,"conversionGoal":338,"date":339,"description":340,"draft":341,"extension":342,"factCheckedAt":338,"faq":343,"featured":341,"language":338,"meta":353,"navigation":354,"order":355,"originalAsset":338,"path":356,"pillar":357,"primaryKeyword":358,"relatedProject":338,"releaseScope":338,"reviewCycle":359,"reviewStatus":360,"reviewedBy":361,"searchIntent":362,"seo":363,"sources":338,"stem":364,"tags":365,"type":371,"updated":338,"__hash__":372},"blog\u002Fblog\u002Fai-product-unit-economics.md","AI Product Unit Economics: Cost, Margin and Control",[7,8,9],"solo-founder","ai-product-builder","indie-hacker",{"type":11,"value":12,"toc":321},"minimark",[13,26,33,38,44,51,54,58,61,149,156,160,165,168,172,179,183,190,194,197,207,211,220,223,227,235,251,255,287,294,297],[14,15,16,20,21,25],"p",{},[17,18,19],"strong",{},"The thing nobody tells you when you bolt a model into a product: you just gave your SaaS a cost of goods sold."," For years the whole appeal of software was that the second user cost basically nothing — build once, sell many, margin near 100%. AI products break that quietly. Every generation, every call, every long context is money out the door, per use, forever. So the question that classic SaaS could ignore — ",[22,23,24],"em",{},"what does one user actually cost me?"," — becomes the question your business lives or dies on. Here's how I think about it, because I'd rather engineer the margin on purpose than discover it's gone at the invoice.",[14,27,28,29,32],{},"I'm going to use round, made-up numbers below purely to show the ",[22,30,31],{},"shape"," of the maths — they're illustrative, not real figures from anything I run. The point is the structure, which holds whatever your actual numbers are.",[34,35,37],"h2",{"id":36},"the-one-number-cost-per-user-vs-revenue-per-user","The one number: cost per user vs revenue per user",[14,39,40,41],{},"Strip everything else away and unit economics is one comparison: ",[17,42,43],{},"what a user pays you, versus what that user costs you in model calls, at the usage they actually reach.",[14,45,46,47,50],{},"That last clause is where people fool themselves. It's easy to model cost at ",[22,48,49],{},"average"," usage and price for that. But cost isn't driven by the average user — it's driven by the heavy one, and in most products a small share of users drive most of the usage. Price for the average and your best-engaged users can be your least profitable, or unprofitable outright.",[14,52,53],{},"So the real question is: at the 90th-percentile usage on a plan, does revenue still comfortably clear cost? If it only works for the median user, it doesn't work.",[34,55,57],{"id":56},"where-the-cost-actually-comes-from","Where the cost actually comes from",[14,59,60],{},"AI cost isn't one number; it's a stack of drivers, and each is a lever you can pull:",[62,63,64,80],"table",{},[65,66,67],"thead",{},[68,69,70,74,77],"tr",{},[71,72,73],"th",{},"Cost driver",[71,75,76],{},"What inflates it",[71,78,79],{},"The lever",[81,82,83,97,110,123,136],"tbody",{},[68,84,85,91,94],{},[86,87,88],"td",{},[17,89,90],{},"Calls per user",[86,92,93],{},"Chatty UX, retries, background jobs",[86,95,96],{},"Fewer, better calls; batch where possible",[68,98,99,104,107],{},[86,100,101],{},[17,102,103],{},"Tokens per call",[86,105,106],{},"Long prompts, big context, verbose output",[86,108,109],{},"Trim context; cap output; structured responses",[68,111,112,117,120],{},[86,113,114],{},[17,115,116],{},"Model choice",[86,118,119],{},"Sending everything to the most expensive model",[86,121,122],{},"Route to the cheapest model that's good enough",[68,124,125,130,133],{},[86,126,127],{},[17,128,129],{},"Repeated work",[86,131,132],{},"Recomputing the same thing",[86,134,135],{},"Cache results and embeddings",[68,137,138,143,146],{},[86,139,140],{},[17,141,142],{},"Failure & abuse",[86,144,145],{},"Loops, retries, scripted\u002Ffree-tier abuse",[86,147,148],{},"Usage caps and a hard ceiling",[14,150,151,152,155],{},"The mindset shift from normal SaaS: ",[17,153,154],{},"cost is now a product-design problem, not just an infrastructure line."," Where you'd once tune a query, you now decide which model runs, on what input, how often, and with what ceiling. Those are design decisions, and they're where margin is won or lost.",[34,157,159],{"id":158},"the-four-levers-in-the-order-i-reach-for-them","The four levers, in the order I reach for them",[161,162,164],"h3",{"id":163},"_1-caching-stop-paying-twice","1. Caching — stop paying twice",[14,166,167],{},"The cheapest call is the one you don't make. If two users (or the same user twice) ask for the same thing, or a step recomputes an identical result, you're paying for work you already did. Cache aggressively — results, embeddings, anything deterministic. It's the highest-return lever and the easiest to skip because it's invisible when it's working.",[161,169,171],{"id":170},"_2-model-routing-cheapest-thats-good-enough","2. Model routing — cheapest-that's-good-enough",[14,173,174,175,178],{},"Not every task needs your most capable model. Classification, extraction, short transforms — plenty of work runs fine on a smaller, cheaper model, with the expensive one reserved for the tasks that genuinely need it. Sending ",[22,176,177],{},"everything"," to the top model is the most common way I see margin quietly evaporate. Route by task, not by habit.",[161,180,182],{"id":181},"_3-usage-caps-bound-the-per-user-cost","3. Usage caps — bound the per-user cost",[14,184,185,186,189],{},"Every plan needs a limit, even a generous one. A cap isn't hostility to users; it's the thing that makes the plan's economics ",[22,187,188],{},"knowable",". Without it, one enthusiastic (or automated) account can cost more than a dozen paying ones. Caps turn \"cost per user\" from a hope into a bounded number you can price against.",[161,191,193],{"id":192},"_4-a-hard-ceiling-survive-the-failure-cases","4. A hard ceiling — survive the failure cases",[14,195,196],{},"Separate from per-plan caps, you need a global \"this should never happen\" ceiling — the backstop for a runaway loop, a bug, or an abuse pattern you didn't foresee. It's the difference between a bad day and a bad invoice. I'd rather a feature fail closed than bill open.",[198,199,200],"pull-quote",{},[14,201,202,203,206],{},"In normal SaaS you optimize cost to improve margin. In an AI product you design cost to ",[22,204,205],{},"have"," a margin. It's not a tuning pass at the end — it's part of what the feature is.",[34,208,210],{"id":209},"free-tiers-and-abuse-free-now-has-a-cogs","Free tiers and abuse: \"free\" now has a COGS",[14,212,213,214,219],{},"This is where AI products diverge most sharply from the SaaS playbook. A free user of a database-backed app costs you rounding-error; a free user of an AI product costs you real money on every action. So the generous free tier that's great marketing for normal SaaS can be a slow leak for an AI one — and ",[215,216,218],"a",{"href":217},"\u002Fblog\u002Fwhy-i-dont-offer-a-free-plan","why I'm cautious about free plans"," is mostly this.",[14,221,222],{},"Abuse turns the leak into a tap: automated signups, disposable accounts, scripted heavy use. The defenses are the same levers, aimed at free: tight free limits, usage caps even on free, and the hard ceiling per account. Not stinginess — arithmetic. \"Free\" is a cost line now, and an unbounded cost line is a business you don't control.",[34,224,226],{"id":225},"pricing-follows-the-economics-not-the-other-way-around","Pricing follows the economics, not the other way around",[14,228,229,230,234],{},"Once you know the real cost-per-user curve, ",[215,231,233],{"href":232},"\u002Fblog\u002Fsubscription-vs-one-time-pricing","pricing"," has to respect it. The trap is pricing on competitor optics or a round number, then discovering the plan loses money at real usage. Two implications I keep front of mind:",[236,237,238,245],"ul",{},[239,240,241,244],"li",{},[17,242,243],{},"Flat pricing needs a cap",", or your heaviest users are your worst accounts. Flat-with-a-limit is honest; flat-with-unlimited-AI is a dare.",[239,246,247,250],{},[17,248,249],{},"Feature-level profitability matters."," Some features are cheap to serve, some are expensive; knowing which lets you shape plans and limits around the economics instead of against them.",[34,252,254],{"id":253},"what-good-looks-like","What good looks like",[236,256,257,263,269,275,281],{},[239,258,259,262],{},[17,260,261],{},"You know cost-per-user at high-percentile usage",", not just the average — and revenue clears it there.",[239,264,265,268],{},[17,266,267],{},"Caching and model routing are designed in",", not retrofitted after the first scary bill.",[239,270,271,274],{},[17,272,273],{},"Every plan has a cap; the account has a hard ceiling."," Cost is bounded by design.",[239,276,277,280],{},[17,278,279],{},"Free is deliberately limited",", because free has a variable cost now.",[239,282,283,286],{},[17,284,285],{},"Pricing respects the cost curve"," — flat plans are capped, and feature economics shape the plans.",[14,288,289,290,293],{},"The old SaaS reflex — build it, margin takes care of itself — is exactly the reflex that sinks an AI product. The good news is that unit economics here is ",[22,291,292],{},"designable",": caching, routing, caps and ceilings are all within your control, and getting them right is as much a part of building the product as the feature itself. Treat cost as a first-class design concern from the start, and you get a product that makes money as it grows. Treat it as an afterthought, and you get one that costs more the more people love it.",[295,296],"hr",{},[14,298,299],{},[22,300,301,302,306,307,311,312,315,316,320],{},"Part of the ",[215,303,305],{"href":304},"\u002Ftopics\u002Fbuilding-ai-products","Building AI Products guide",". See also ",[215,308,310],{"href":309},"\u002Fblog\u002Fhow-i-use-ai-without-letting-ai-decide","how I use AI without letting AI decide"," and ",[215,313,314],{"href":232},"subscription vs one-time pricing",". The ",[215,317,319],{"href":318},"\u002Fnewsletter","newsletter"," sends one finance-systems pattern, product decision or build lesson every two weeks.",{"title":322,"searchDepth":323,"depth":323,"links":324},"",2,[325,326,327,334,335,336],{"id":36,"depth":323,"text":37},{"id":56,"depth":323,"text":57},{"id":158,"depth":323,"text":159,"children":328},[329,331,332,333],{"id":163,"depth":330,"text":164},3,{"id":170,"depth":330,"text":171},{"id":181,"depth":330,"text":182},{"id":192,"depth":330,"text":193},{"id":209,"depth":323,"text":210},{"id":225,"depth":323,"text":226},{"id":253,"depth":323,"text":254},"economics",null,"2026-07-28","An AI product has a variable cost per use that most SaaS doesn't. How I think about token\u002FAPI cost per user, gross margin, caching, model routing, free-trial abuse and cost caps.",false,"md",[344,347,350],{"question":345,"answer":346},"What are unit economics for an AI product?","Unit economics for an AI product are the revenue and cost attached to a single unit — usually a user or an account — with one twist that most SaaS doesn't have: a real variable cost per use, driven by model or API calls (tokens). In classic SaaS, serving one more user costs almost nothing, so gross margin is very high by default. In an AI product, every generation, every call, every long context costs money, so margin has to be engineered rather than assumed. The core question is simple and unforgiving: does the revenue from a user comfortably exceed what that user costs you in model calls, at the usage level they actually reach — not the level you hoped for?",{"question":348,"answer":349},"How do you control AI model costs in a product?","With a handful of levers, used deliberately: cache results so you don't pay twice for the same work; route each task to the cheapest model that's good enough rather than sending everything to the most expensive one; cap usage per user or per plan so a single account can't run up an unbounded bill; and set a hard ceiling that stops runaway cost even in the failure cases (a loop, an abusive user, a bug). The mindset shift from normal SaaS is that cost is now a product design problem, not just an infrastructure line — where you'd once optimize a database query, you now decide which model runs, on what, how often, and with what ceiling.",{"question":351,"answer":352},"Why is free-trial abuse a bigger risk for AI products?","Because a free user of a normal SaaS costs you almost nothing, but a free user of an AI product costs you real money on every action — so a generous free tier that's fine for a database-backed app can quietly bleed cash for an AI one. Abuse amplifies it: automated signups, disposable accounts and heavy scripted use turn a marketing cost into an open tap. That's why AI products lean toward tighter free limits, usage caps even on free, and a hard per-account ceiling — not because they're stingy, but because 'free' has a variable cost that has to be bounded or it becomes the whole P&L.",{},true,8.5,"\u002Fblog\u002Fai-product-unit-economics","building-ai-products","AI product unit economics","annual","reviewed","Tan Gravam","informational",{"title":5,"description":340},"blog\u002Fai-product-unit-economics",[366,367,233,368,369,370],"ai-products","unit-economics","margin","model-cost","solo-saas","text","lZY_bGSqNOxDe7zc16NGsAx9x5KZYn6oM0XWtCzp5ac",[374,378],{"title":375,"path":376,"stem":377,"type":371,"language":338,"draft":341,"children":-1},"AI Output Contracts & Failure Handling","\u002Fblog\u002Fai-output-contracts-and-failure-handling","blog\u002Fai-output-contracts-and-failure-handling",{"title":379,"path":380,"stem":381,"type":371,"language":338,"draft":341,"children":-1},"Audit Trails and Logging in Treasury Systems","\u002Fblog\u002Faudit-trails-and-logging-treasury-systems","blog\u002Faudit-trails-and-logging-treasury-systems",[383,387,391],{"path":384,"title":385,"description":386},"\u002Fblog\u002Fmy-product-operating-system","My Product Operating System for Building Multiple AI Apps","The product operating system I use to build several focused AI products solo: choosing which problem to build, shipping fast, and killing what isn't working.",{"path":388,"title":389,"description":390},"\u002Fblog\u002Fhow-i-decide-whether-an-ai-product-idea-is-worth-building","How I Decide Whether an AI Product Idea Is Worth Building","How to decide what product to build: the short filter I run every idea through — real recurring problem, one-sentence outcome, small enough to ship solo.",{"path":392,"title":393,"description":394},"\u002Fblog\u002Fwhy-i-write-the-expected-output-before-the-screen","Why I Write the Expected Output Before the Screen","Define the outcome before design: I write the exact result the user should get before building any screen, because the screen is only the path to an outcome.",1785237637128]