The New P&L: Why AI Economics Are Now Integral to Product Strategy

For thirty years, the economics of building software followed a predictable pattern. You paid engineers to write code. You paid for servers to run it. Once built, the marginal cost of serving one more customer was close to zero. That was the whole magic of software as a business. Build once, sell infinitely, watch gross margins climb toward 80 or 90 percent as you scaled.

AI breaks that pattern. When a product relies on a large language model to do real work, every single use of that product costs money. Not a fixed cost amortized over millions of users. A variable cost, per call, every time. This is the central shift in product economics, not a finance footnote. Companies that treat AI economics as an afterthought are building on sand.

The Three Prices of a Token

Every interaction with a language model has a cost structure, and it is more complex than most product teams initially assume. There are three components worth separating.

Input tokens are the cost of everything you send the model: the user’s prompt, the system instructions, any retrieved documents, conversation history, tool definitions. This is often the largest and most controllable line item, because it scales with how much context your product decides to stuff into every call.

Reasoning tokens, now common with reasoning-capable models, are a newer and less intuitive cost. The model spends tokens reasoning before it produces a visible answer, and the company pays for that reasoning even though the user never sees it directly. A product that invokes extended reasoning for every trivial request is paying a tax it may not need to pay.

Output tokens are what the user actually sees, and they are typically priced higher than input tokens because generation is more computationally expensive than reading. A verbose model, or a product design that encourages long responses, directly inflates cost.

These three costs behave completely differently depending on how a product is built. During internal development, teams often treat token cost as an abstraction, something to worry about later, because early usage is small and covered by testing budgets. That is a mistake. The prompt engineering decisions made in the first month of development, including how much context gets attached to a call, whether reasoning mode is on by default, and whether the system asks for a paragraph or a page, become permanent cost structures once the product ships. Nobody goes back and re-architects a prompt pipeline for cost efficiency once it is generating revenue, and frankly, nobody wants to touch it. That means the economics get baked in early, often by engineers optimizing for demo output quality and not unit economics at scale.

When the Product Needs AI to Function

A critical distinction exists between AI used to build a product and AI used to run a product. A team might use Claude or GPT to write code, generate test cases, or draft documentation during development. Those costs disappear once the product ships. They are a one-time, internal cost of production, no different in kind from paying a contractor.

But when the product itself calls a model in production, every single customer interaction carries a live cost. A customer support tool that uses AI to answer support tickets pays a token cost every single time a customer submits a ticket. A writing assistant pays a token cost every time a user asks for a paragraph. This is not a sunk cost. It is a recurring cost that scales linearly, or worse than linearly, with usage.

This changes the entire calculus of what “a customer” is worth. In traditional software, a customer who logs in ten times a day and one who logs in once a month cost the company roughly the same to serve. In an AI-native product, the heavy user might cost ten times more to serve than the light user, even if both pay the same subscription fee. This is the most important shift AI has introduced for product economics. It means product teams must now fully understand their cost-to-serve at the level of an individual customer. They can no longer just aggregate cost of goods sold.

The Volatility Problem

Token prices are not static, and they have moved dramatically, in both directions, over the past several years. A provider drops prices by 50 percent overnight because a competitor released a cheaper model. A provider raises prices, or deprecates a cheap model in favor of a more expensive one, and a company’s cost structure shifts without warning.

This creates a strategic vulnerability that traditional software companies never had to plan for. Imagine a product priced at $49 a month, built on the assumption that the average customer generates $8 of token cost per month, leaving a healthy margin. If the underlying model provider raises prices, or the company needs to upgrade to a more capable and more expensive model to stay competitive on quality, that $8 might become $20. The margin compresses instantly, without the company changing anything about its own product or its pricing.

The question every AI product team eventually has to ask is this: if token costs rose sharply tomorrow, does the product still work as a business? If the answer is no, the product was never actually viable. It was viable only because of a temporary, ephemeral price environment. This is not a hypothetical risk. It has already happened to companies that built thin wrappers on top of a single model provider with no cost buffer and no fallback plan.

Building Products That Can Absorb Cost Shocks

The good news is that this risk is manageable, and the companies that manage it well are building genuine competitive advantage rather than just avoiding disaster.

The first lever is architectural flexibility. Products that are hard-coded to a single model from a single provider have no negotiating leverage and no fallback if that provider’s pricing or availability changes. Products designed with an abstraction layer that can route requests to different models, based on task complexity or cost sensitivity, can respond to price shocks by shifting traffic rather than absorbing the full hit.

The second lever is model selection appropriate to use cases and tasks. Not every task in a product needs the most capable, most expensive model available. Classifying an email as spam or not spam does not require the same model as drafting a complex legal analysis. Companies that build tiered pipelines, routing simple tasks to cheap, fast models and reserving expensive reasoning models for genuinely hard problems, build in cost resilience by design. This also benefits quality, since it forces genuine discipline about where AI capability actually adds value.

The third lever is aggressive context management. Because input tokens scale with everything attached to a call, disciplined engineering is required around what actually needs to be in the prompt: trimming unnecessary history, summarizing rather than repeating, and retrieving only the most relevant documents rather than everything available has a direct and often underappreciated effect on cost per transaction.

The fourth lever is caching and reuse. Many products send substantially similar or identical prompts repeatedly. Caching common responses, or using prompt caching features that some providers now offer, can meaningfully cut costs without touching the product experience at all.

None of these are exotic. They are basic engineering discipline. But they require product and engineering leadership to treat cost per transaction as a first-class metric from day one, not something to optimize after a funding round runs low.

The Maintenance Bill Nobody Budgeted For

Another cost that rarely shows up in the early excitement around AI-assisted development tends to arrive much later, quietly, in the form of an engineering team that cannot move as fast as it used to. That cost is maintenance, and AI changes its shape in two important ways.

The first is code comprehension debt. AI-generated code can be fast to produce and functionally correct on day one. But it is not always written the way a human engineer would, when also considering the next three years of maintenance. It can be verbose, inconsistently structured, or solved in a roundabout way that made sense to the model in the moment but does not reflect how the rest of the codebase thinks about a problem. This is manageable when the person who prompted it is still around to explain the reasoning, answer questions, and translate intent back into context. It becomes a real liability the moment that person leaves the company. The next engineer inherits code with no memory of the prompt, the assumptions, or the tradeoffs that produced it, only the artifact itself. Debugging it, extending it, or safely removing it takes longer than it would for code a human wrote with the next maintainer in mind. That lost time is a real cost, and it belongs on the same balance sheet as token spend, even though nobody bills for it directly.

The second is feature bloat, and it is arguably the more dangerous of the two because it looks like progress. When the cost of building a new feature drops toward zero, the natural discipline that used to prevent shipping bad features, namely the internal debate over whether an idea is worth weeks of engineering time, weakens. Ideas that would never have survived a serious prioritization conversation now get built simply because it is cheap and fast. The problem is that shipping a feature is not the expensive part. Every feature that ships must be maintained, tested against every future change, secured, documented, and supported, indefinitely, regardless of how many customers actually use it. Cheap to add does not mean cheap to keep. A product can accumulate dozens of half-used, never-quite-vetted features this way, each one a small tax on every future release cycle, until the codebase is carrying a maintenance load that has nothing to do with the value it delivers to customers. The only way out of that trap is deliberate deprecation, and deprecation requires the same discipline that used to happen naturally when features were expensive to build. Companies that let AI lower the cost of creation without strengthening the discipline of what potential features don’t make it to production are trading a short-term velocity gain for a long-term maintenance burden that compounds quietly until it cannot be ignored.

From License Fees to Metered Usage

This cost structure is also driving one of the more significant business model shifts in software history: the move away from flat subscription pricing toward usage-based pricing.

Traditional software pricing worked because the marginal cost of serving a customer was near zero. Charging everyone the same monthly fee, regardless of how much they used the product, made sense because usage did not meaningfully affect the company’s costs. AI inverts this. When cost genuinely scales with usage, flat pricing becomes a bet that average usage will stay within a profitable band, and heavy users become a direct drag on margin rather than simply a sign of product success.

This is why so many AI-native products now price on tokens, credits, seats combined with usage caps, or per-transaction fees rather than pure flat subscriptions. It is not a marketing trend. It is a rational response to a cost structure that did not exist in the software industry before. Companies now need to know their AI cost per transaction with real precision, the same way a manufacturing company needs to know its cost of goods per unit, because that number determines pricing, determines which customer segments are profitable, and determines whether growth in usage is good news or a margin problem.

This is uncomfortable for product teams used to the simplicity of flat SaaS pricing, but it is also more honest. It aligns what a customer pays with what a customer actually costs to serve, and it forces genuine visibility into unit economics that many software companies never had to develop before.

Return on AI Is the Metric That Matters

All of this points to a single, larger idea. Adopting AI is not, by itself, an achievement. It is not a strategy. It is a cost. The metric that actually matters for the company building the product and for the customer deciding whether to buy it is return on AI (RoAI).

For the company, return on AI means the value created by using AI, including faster development, better product quality, and new capabilities that were previously impossible, must exceed the token cost of delivering it, plus the margin the business needs to survive and reinvest. A company can be a heavy, sophisticated user of AI and still lose money on every transaction if it never does this math seriously.

For the customer, the same principle applies in reverse. A customer will not pay for AI capability because AI is impressive. They will pay because the outcome the AI delivers, whether it is time saved, better decisions made, or work that no longer needs to be done manually, is worth more to them than the price of the product. If a customer cannot draw a straight line from what they are paying to a return they can measure, the AI features are decoration, not value.

This discipline will separate durable AI products from the wave of thin, undifferentiated tools currently flooding the market. Impressive demos are not a business model. Token costs are real. They shift, and they compound across every customer interaction. The companies that win will treat AI economics not as an engineering detail buried in a cloud bill, but as a core, ongoing input to product strategy, pricing, and customer value. That is simply the new reality of building products in the AI era. Ignore it at your peril.