The Cost-First AI Product Launch Playbook

Builder-to-builder. I have launched AI products that lost money on every active user and did not find out until the bill arrived. This is the playbook I wish I had used the first time.

The number that should scare you

By June 2026, the math on AI products stopped being a debate. The token tax, the running levy you pay on inference you do not own, eats about 23 percent of revenue at scaling-stage AI companies. That single line item drags AI gross margins roughly 30 points below the traditional SaaS baseline. Software founders spent fifteen years assuming 80 percent gross margins were a law of nature. They were a feature of a business where serving the next customer cost almost nothing. That world is gone for anyone shipping AI.

Here is the durable version, stripped of this week’s headlines. When you ship an AI product, every request runs a server somewhere doing real work, and someone sends you a bill for it. The bill scales with usage. The more your product gets used, the more you pay. That is the opposite of the SaaS curve that made software the best business model ever invented, and most founders are still launching as if the old curve applies.

The receipts are not hypothetical. Cursor, the fastest-growing AI coding tool of its era, ran at negative gross margins through most of 2024 and 2025. By January 2026 it was reportedly paying around 650 million dollars a year to its model providers against roughly 500 million in revenue, a gross margin of negative 23 percent. It cost more to run the product than the company collected. OpenAI, the most-funded company in the category, is projected to lose 14 billion dollars in 2026 against about 13 billion in sales, with inference costs at points exceeding subscription revenue. If the biggest players in the world are underwater on unit economics, the solo founder shipping a wrapper on Friday afternoon needs a different plan than “we’ll figure out margins later.”

That different plan is what this post is. I call it cost-first launch. You design the cost structure of the product before you design the features, because in AI the cost structure is a product decision. Get it wrong and you ship something that gets more expensive every time it succeeds.

Why the SaaS launch playbook breaks on AI

The standard software launch playbook is value-first, and it works beautifully for SaaS. You build the thing, prove people want it, charge a subscription, and ignore cost of goods sold because there basically isn’t any. Hosting a few more users on a database costs rounding-error money. So the playbook says: get traction first, optimize later, margins take care of themselves at scale. Every accelerator, every blog post, every investor deck for two decades baked that assumption in.

AI inverts it. The cost of serving a user is no longer near zero. It is a meaningful, usage-linked, hard-currency expense that shows up before you pay a single engineer. For every million dollars of AI product revenue booked in 2026, roughly 230,000 dollars goes straight out the door as inference before payroll, before marketing, before rent. The application layer, where most founders build, runs even thinner. App-layer AI margins sat around 33 percent in 2024 and climbed to maybe 45 percent in 2026. That is half of what a SaaS founder expects.

Three things break when you run the old playbook on the new economics.

First, “optimize later” becomes “optimize never,” because by the time you notice the problem you have a usage pattern, a price point, and a base of customers all built on top of a broken cost assumption. Changing any of them now means breaking promises. Cursor learned this in mid-2025 when it changed pricing to fix the math, set off a revolt, and the CEO had to publish a public apology and refund affected users. The fix was correct. The timing, after launch instead of before, made it expensive and public.

Second, growth stops being a strategy and becomes a risk. In SaaS, more users is unambiguously good. In AI, more users means more inference, and if your price does not cover your marginal cost, every new signup widens the loss. One failed AI productivity startup I read the post-mortem on had a customer acquisition cost of 180 dollars and a lifetime value of 240. On paper a 1.3 ratio looks survivable. In practice they were spending to acquire customers who cost more to serve than they paid. Scaling that is not growth. It is a faster way to run out of money.

Third, you lose your pricing freedom. If you launch with an unlimited-usage subscription because that is what users expect, and your costs are usage-linked, you have signed an open-ended liability. The Anthropic disclosure from July 2025 made this concrete: a single heavy user on a 200-dollar-a-month plan could consume tens of thousands in model usage. By Cursor’s own analysis, a 200-dollar Claude Code subscription could translate into roughly 5,000 dollars of underlying compute for a power user. Flat pricing on metered costs is a bet that your heaviest users stay light. They never do.

None of this means AI products are bad businesses. It means the launch sequence has to change. You cannot bolt cost discipline on after you find product-market fit. You have to build the product so the economics work at the first paying customer and get better, not worse, as you grow.

The AI Margin Waterfall (the framework)

Before you can launch cost-first, you have to see where the money actually goes. Most founders picture their P&L as revenue minus salaries. For an AI product, the interesting part happens before salaries, in the gap between the dollar a customer pays and the cents you keep. I draw it as a waterfall, because that is what it looks like: a dollar of revenue stepping down through a series of deductions until you reach the margin you actually keep.

The framework is one idea: every cost-first launch decision is a fight to keep the waterfall from dropping further than it has to. You do not get to remove the model tax, it is the cost of building on inference. But you control how much of it you pay, how many hidden tokens you generate, how much infra you bolt on, and what price sits at the top of the chart. Cost-first launch means you decide those four things on purpose, before customers lock the shape in.

The rest of this post walks the waterfall top to bottom, then gives you the ladder to climb back up. If you want the wider operating model this sits inside, I wrote it up as the solo founder AI-native operating system, where cost is one of six loops. This post is the deep dive on that loop.

Section 1: The token tax is real and it compounds

The token tax is the share of every dollar that leaves as inference cost. At scaling-stage AI companies it runs around 23 percent of revenue, and unlike most costs it does not enjoy economies of scale in your favor. You pay per token, and your provider’s price is your floor. You can negotiate volume discounts at serious scale, but you do not control the underlying cost of the model, and you are competing for margin against the company that sells you the model.

This is why the gross-margin gap is structural, not a phase. Across 2026, healthy AI-native businesses run gross margins around 50 to 60 percent while the fastest-growing ones sometimes run at 25 percent or negative. Traditional SaaS sits at 70 percent and up. The compression is not because AI founders are sloppy. It is because the cost of serving a request is built into the product in a way it never was for software that just moved bytes around a database.

The compounding part is what catches people. The token tax does not just take a fixed bite. It grows with three things at once: usage per customer, complexity of each request, and the number of model calls hiding inside a single user action. A SaaS feature costs the same whether a user clicks it once or a thousand times. An AI feature costs more every single time. When your product gets better and people use it more, your cost line rises in lockstep with your usage line. If your revenue line does not rise faster, you are scaling toward zero.

Here is the part founders miss at launch. The token tax is set the moment you choose your default model and your default prompt design. If you wire everything to the most capable frontier model because it is the easiest way to get a demo working, you have just locked in the highest tax rate in the market as your baseline. Demos do not have a P&L. Products do. The gap between “it works in the demo” and “it works as a business” is almost entirely this decision, and it is far cheaper to make it right at launch than to re-architect after you have customers depending on a behavior you can no longer afford.

Section 2: The three bills founders never see

When founders estimate AI cost, they price the visible tokens: the user’s input and the model’s output. That is the bill they imagine. There are two more bills they do not see until the statement arrives, and a third that hides in plain sight.

The first hidden bill is reasoning and retry tokens. Modern models burn tokens thinking before they answer, and agent loops generate calls you never wrote into the happy path. Every retry after a failure, every step in a multi-step chain, every internal reasoning pass is billed at the same rate as the words your user reads. If you have not instrumented your product to count these, you do not actually know your cost of goods sold. You know a fraction of it. I have seen products where the invisible tokens outnumbered the visible ones by three to one. The user saw a paragraph. The bill was for a small novel.

The second hidden bill is infrastructure overhead. Hosting, monitoring, logging, vector storage, and the security plumbing around your models add up to roughly 10 to 15 percent of your inference cost on top of the inference itself. It is not a rounding error at scale, and it grows as you add the observability you need to run responsibly. If you are running agents with real permissions, that overhead climbs further, which is a good reason to read how the agent identity gap leaks before you wire an agent to your production systems.

The third bill is not hidden so much as ignored: the cost of being wrong. When your model produces a bad output, you pay for the bad output, then you pay again for the user’s correction, the retry, the support ticket, and sometimes the refund. Quality is a cost lever. A product that gets it right the first time spends fewer tokens than one that needs three tries, which is one reason I treat evals as an economic tool, not just a quality one. I walked through that in the evals playbook for solo founders: every percentage point of reliability you buy is also a percentage of wasted retry spend you stop paying.

Put the three together and the lesson is simple. Your real COGS is visible tokens, plus invisible tokens, plus infra, plus the tax on being wrong. If you launch pricing against only the first one, you are pricing against a number that is off by a factor of two or more. Instrument all of it before you set a price.

Section 3: The Cost-First Launch Ladder

Knowing where the money goes is half the job. The other half is a launch sequence that keeps the waterfall shallow from day one. I run it as a ladder with five rungs. You climb them in order, and each rung recovers margin the one below it could not.

Rung one, prove value. This is the only rung where ignoring cost is allowed, and even here only for a short window. You ship something rough to real users, on whatever model gets it working, to confirm people actually want the thing. The SaaS playbook stops here and stays here. Cost-first launch treats this as a sprint, not a season. The moment you have signal that the value is real, you climb.

Rung two, instrument cost. Before you optimize anything, you have to be able to see it. Log tokens per request, per user, and per feature, and make sure you are counting the hidden reasoning and retry tokens, not just the visible ones. The goal is a single number you trust: fully loaded cost per user action. Until you have it, every optimization is a guess. With it, you can rank what to fix by how much it actually costs.

Rung three, route to right-sized models. Stop sending every request to the most expensive model. Send simple tasks to small, cheap, fast models and reserve the frontier model for the genuinely hard work. This one lever cuts inference cost 30 to 60 percent in mixed workloads, and it is mostly invisible to the user if you do it well. More on this below, because it is the highest-payback move most founders skip.

Rung four, cache repeat work. A large share of requests in most products are near-identical to ones you have already answered. Reusing computed results for repeated or similar prompts cuts cost 50 to 90 percent on cache-eligible workloads. For high-reuse products, caching often returns more savings than months of routing work. It is the cheapest thing on the ladder to install and the most often forgotten.

Rung five, price to value. Once your cost per action is measured and minimized, set a price that captures the value you create and protects you from the heavy user. This is not about charging more. It is about aligning what you charge with what it costs you to deliver, so that more usage means more margin instead of more loss. The exact pricing mechanism is its own subject. The point here is that pricing is the last rung, not the first, because you cannot price intelligently against a cost you have not measured and minimized.

The reason the order matters: each rung makes the next one cheaper and more accurate. Pricing before instrumenting is guessing. Routing before instrumenting is optimizing blind. Caching before routing leaves easy money on the table. Climb in order.

Section 4: Model routing is the highest-payback lever

If you only do one thing from this post, do this one. The single biggest reason AI products run thin margins is that founders default everything to the most capable model because it is the path of least resistance to a working demo. The frontier model is the Swiss Army knife you reach for when you do not yet know which blade you need. But running every request through it is like hiring a senior specialist to answer the front desk phone. It works, and it is wildly overpriced for most of the calls.

Routing means classifying each request by how hard it really is, then sending it to the cheapest model that can handle it. Classification, intent detection, short lookups, simple extraction, and formatting go to small, fast, cheap models. Long-form generation, multi-document synthesis, and genuinely hard reasoning go to the frontier model. The user does not care which model answered. They care that the answer is right and fast. Routing lets you give them that while paying a fraction of the blended cost.

The objection I hear is that routing adds complexity, and a solo founder does not have time to build a routing layer. Two answers. First, you do not need a fancy classifier to start. A few rules based on request length, the presence of certain keywords, or which feature the call comes from will capture most of the savings. Second, the cost of not routing is not abstract. It is the difference between a product that survives its own success and one that gets more expensive every time it grows. The routing layer is cheaper than the bill it prevents.

Here is a starting cheat sheet. It is not gospel; it is a default you tune against your own instrumented numbers.

Cursor’s own arc proves the point at scale. For most of 2024 and 2025, every query routed to a third-party frontier model, and every token flowed straight out of gross margin. In November 2025 the company shipped its own in-house model tuned for code, specifically so that the common case no longer had to pay the frontier provider. That is routing taken to its logical end: when a task is frequent and well-defined enough, the cheapest model is one you control. Most founders will never build their own model, and should not. But the lesson scales down. The frequent, well-defined work in your product is exactly the work you should move off the most expensive model first.

Section 5: Caching beats cleverness

Caching is the least glamorous lever and often the most profitable. The idea is simple: if you have already computed an answer to a request, do not pay to compute it again. For workloads with a lot of repetition, and most consumer-facing AI products have more repetition than founders think, prompt caching and result caching cut costs 50 to 90 percent on the eligible calls. For a high-reuse product, a day spent on caching can beat months spent on routing infrastructure.

The reason it gets skipped is that it feels like it is beneath the product. Founders want to spend their time on the model behavior, the prompt design, the clever agent loop. Caching is plumbing. But plumbing is where the money leaks. I have watched a product cut its bill by more than half in a week, not by changing a single thing the user could see, but by noticing that a third of its requests were the same handful of questions asked over and over, and answering them from a cache instead of the model.

There is a discipline point hiding here that goes beyond caching. The cost work that pays best is usually invisible to the user and unglamorous to the builder. Routing, caching, trimming context, cutting retry loops. None of it shows up in a demo or a launch tweet. All of it shows up in the bank account. Cost-first launch means giving the unglamorous work the same priority you give the visible features, because in AI the unglamorous work is what makes the visible features affordable to run. The context discipline that keeps token counts low is the same discipline I covered in the internal AI stack for solo founders, where keeping the build lean is itself a cost strategy.

One caution so this stays honest. Caching trades freshness for cost, so it is wrong for anything that must be live or personalized to the moment. The skill is knowing which requests are safe to cache, and instrumenting from rung two tells you which ones repeat. You cache the repetitive and stable, and you pay full price for the unique and time-sensitive. Done blindly, caching serves stale answers. Done from data, it is the cheapest margin you will ever recover.

The contrarian take: growth does not fix this

The most expensive belief in AI right now is the one inherited straight from SaaS: that growth fixes margins. In software it usually did. Fixed costs spread over more users, marginal cost stayed near zero, and a company could lose money for years on its way to a fat margin at scale. Investors learned to fund the growth and wait for the margin. That instinct is now actively dangerous.

In AI, scale amplifies the loss before it produces the profit. Each additional user adds revenue, yes, but also adds compute, electricity, and the depreciation of expensive hardware somewhere up the stack. If your price does not exceed your cost to serve, growth does not close the gap. It widens it, faster. The named enemy here is the “get big, fix margins later” reflex itself. It is not a neutral default. It is a specific bet that your cost curve behaves like SaaS, and for AI products that bet is wrong.

Look at the pattern across the category. OpenAI’s losses are projected to triple to 14 billion dollars in 2026 even as revenue grows, because the cost of serving grows with it. Cursor grew faster than almost any company in history and was still underwater on every heavy user until it changed its architecture and its pricing. These are not small, undisciplined startups. They are the best-resourced companies in the field, and growth alone did not save their unit economics. Something structural had to change.

So the contrarian move is to treat cost as a product feature you ship on day one, not a finance problem you defer to a future raise. The founders who win the next few years will not be the ones who grew fastest. They will be the ones whose products got cheaper to run as they scaled, because they designed for that from the launch. Growth is still good. But in AI, growth is only good if the unit economics are already positive. Otherwise you are just buying a bigger problem.

There is a healthy counterpoint worth stating plainly. Sometimes a land-grab is the right call, and you accept negative margins to win a market before competitors lock it up, planning to fix economics from a position of strength. That can be correct, and a few category winners will do exactly that. But it is a deliberate, well-funded, eyes-open bet, not a default you fall into because you forgot to do the math. The danger is not founders who choose to subsidize growth on purpose. It is founders who are subsidizing it by accident and calling it traction.

What to do Monday morning

Concrete and tactical. If you are about to launch an AI product, or you launched one and have never seen your true cost per user, here is the week.

Monday: instrument. Add token logging to every model call. Capture input tokens, output tokens, and any reasoning or retry tokens your provider exposes. Tag each call by feature and by user. By end of day you want to be able to answer one question: what does a single user action cost me, fully loaded? If you cannot answer it, nothing else this week is reliable.

Tuesday: find your blended cost and your whale. Compute cost per active user and cost per action. Then find your single heaviest user and see what they cost you against what they pay. That one user tells you whether your pricing has an open-ended liability hiding in it. If your heaviest user costs more than they pay, your pricing is a bet you will lose at scale.

Wednesday: route the obvious wins. List your model calls by volume. Take the highest-volume, lowest-difficulty calls, classification, simple lookups, formatting, and move them to a smaller, cheaper model. Do not build a perfect router. Build three rules. Measure the bill before and after. You are looking for a 30 percent-plus cut on those call types.

Thursday: cache the repeats. Look at your request logs for the questions or inputs that recur. Add a cache for the stable, repetitive ones. Be conservative about what is safe to cache, lean on your Tuesday instrumentation to find the high-reuse calls, and leave the unique and time-sensitive ones at full price. Measure the bill again.

Friday: price against the real number. Now that you know your fully loaded cost per action and you have cut it, set or revise your price so that your typical user is clearly profitable and your heaviest user cannot bankrupt you. If you are pre-launch, this is free to do. If you have customers, plan the change carefully, because changing pricing after launch is the expensive path Cursor walked. Better to never need to.

That is one week. It will not make your margins look like SaaS, nothing will, but it will move you from flying blind to flying with a fuel gauge. The founders who survive the next stretch are the ones who can see the gauge. If you want to put this inside a broader weekly operating rhythm, the founder operating system is where I keep the cost loop alongside everything else a one-person company has to run, and the wider map of where AI businesses are winnable is in the AI opportunity map.

Frequently asked questions

What does cost-first AI product launch actually mean?

It means you design and measure the cost structure of your AI product before you set features and pricing in stone, rather than launching value-first and optimizing cost later. Because AI products carry real, usage-linked marginal cost, the cost decisions made at launch, which model is the default, how prompts are designed, what gets cached, are also product decisions. Cost-first launch makes those choices deliberately and early, when they are cheap to change.

Why are AI gross margins lower than SaaS gross margins?

Traditional SaaS serves the next customer for almost nothing, so margins sit at 70 percent and up. AI products pay real inference cost on every request, a token tax that runs around 23 percent of revenue at scaling stage and drags gross margins roughly 30 points below the SaaS baseline. AI-native businesses commonly run 50 to 60 percent gross margins, and application-layer products often less. The gap is structural, not a sign of poor execution.

How much can model routing and caching actually save?

Intelligent routing, sending simple tasks to small cheap models and reserving the frontier model for hard work, cuts inference cost 30 to 60 percent in mixed workloads. Prompt and result caching cuts 50 to 90 percent on cache-eligible, high-reuse calls. Combined with appropriate model selection and infra efficiency, systematic optimization commonly reaches 70 percent or more cost reduction, often while improving output quality.

What are the hidden costs founders miss when estimating AI COGS?

Three. Reasoning and retry tokens, which are billed at full rate and can outnumber the visible input and output tokens. Infrastructure overhead, hosting, monitoring, logging and security, which runs about 10 to 15 percent of inference cost. And the cost of being wrong, where a bad output is paid for once, then again in retries, support, and refunds. Real COGS is all of these, not just the visible tokens.

Isn’t it fine to lose money early and fix margins at scale like SaaS startups did?

It can be, but only as a deliberate, well-funded land-grab, not a default. In SaaS, scale fixed margins because marginal cost was near zero. In AI, scale amplifies losses first, because every new user adds compute cost. OpenAI’s losses are projected to grow with revenue, and Cursor was underwater on heavy users despite record growth. Growth fixes AI margins only when the unit economics are already positive.

How do I price an AI product so heavy users don’t bankrupt me?

Price last, after you have instrumented and minimized cost per action, and align price with the value delivered rather than a flat unlimited subscription on metered costs. A single heavy user on flat pricing can consume many times what they pay, as disclosed cases in 2025 showed a 200-dollar plan generating thousands in compute. Cap or meter the heaviest usage so that more usage produces more margin, not more loss.

What’s the first thing to do if I already launched without measuring cost?

Instrument immediately. Add token logging to every model call, including reasoning and retry tokens, tagged by feature and user, until you can state your fully loaded cost per user action. Then find your heaviest user and compare what they cost against what they pay. That single comparison tells you whether your current pricing hides an open-ended liability, and it ranks every optimization by real dollars.

Does cost-first launch slow down shipping?

No, because it is sequenced, not front-loaded forever. You still ship fast on rung one to prove value, ignoring cost briefly. The discipline is climbing off rung one within weeks instead of staying there for a year. Instrumenting, routing, and caching are days of work each, not quarters, and they pay for themselves by preventing a re-architecture and a painful pricing change after you already have customers.

I build AI-native ventures as a solo founder and write the playbooks as I go. If this was useful, the rest of the AI-native founder playbook goes deeper on building lean, shipping reliably, and keeping the economics honest.