The most expensive architectural decisions are sometimes made in a pricing meeting. A team chooses “per seat,” “per API call,” or “per completed task,” then treats implementation as a billing integration to be added near launch. Yet this practical examination of liquidity, unit economics, and decision discipline points to a harder truth: businesses fail when the timing and incentives behind the numbers are wrong. In software, those incentives are not confined to a spreadsheet. They are compiled into the product. Your pricing metric determines what the system must measure, how customers behave, where margin can disappear, and whether growth creates cash or simply creates more load.
That is why pricing should be reviewed with the same seriousness as a database model or a public API. Once customers build budgets, workflows, and procurement rules around it, changing the model becomes a migration problem. The pricing page is only the documentation. The real product is the economic protocol underneath it.
Pricing Is a Protocol, Not a Page
Every software pricing model contains an implicit contract.
It defines an event: a seat is activated, a record is processed, a message is delivered, a report is generated, or a task is completed. It defines who owns that event, when it becomes billable, how it is counted, and what happens when the event is retried, reversed, disputed, or produced late. It also defines the relationship between customer value and vendor cost.
When those definitions are vague, the ambiguity does not stay in finance. It leaks into product requirements, data pipelines, customer support, sales negotiations, and engineering priorities.
Suppose a sales team promises to bill only for “active users.” Engineering still needs an exact definition. Is a user active after logging in once, opening a notification, making an API request, or completing a workflow? Does activity expire after seven days or thirty? Are service accounts included? What happens when an employee leaves halfway through the month?
If the contract, application, warehouse, and invoice use different definitions, the company has created four versions of the same truth.
That is not a reporting problem. It is a broken interface.
The best time to discover this is before the pricing model is announced. The worst time is when a large customer asks why the invoice does not match the usage screen inside the product.
The Metric You Charge For Changes the Product
Pricing is usually discussed as a way to capture value, but it also shapes behavior.
Per-seat pricing encourages customers to restrict access, share accounts, or reserve licenses for a small group of power users. That may be acceptable for software whose value is closely tied to individual users. It becomes awkward when automation allows one person to trigger the work that previously required twenty.
Per-request pricing creates a different set of incentives. Customers batch requests, cache results, reduce polling, and redesign integrations around the meter. In some products, that makes the entire ecosystem more efficient. In others, it discourages the very usage that creates customer success.
Outcome-based pricing appears more aligned because the customer pays when something useful happens. But “useful” is much harder to define than “called an endpoint.” A support ticket can be marked resolved and reopened two hours later. A fraud alert can be technically correct but operationally useless. An AI agent can complete a task while creating downstream work for a human.
The closer the billing unit moves toward customer value, the more interpretation enters the system. The closer it moves toward raw consumption, the easier it is to count but the harder it may be for customers to connect the bill to an outcome.
There is no universally correct metric. There is only a metric whose tradeoffs have been made explicit.
A Billable Unit Has to Pass Four Tests
Before a team commits to a pricing metric, the unit should survive four questions:
- Can the customer predict it? A buyer should be able to estimate spend using information they already understand.
- Can the product attribute it? Every billable event should belong to the correct customer, workspace, contract, and pricing version.
- Can both sides audit it? The number on the invoice should be explainable from records that can be inspected and reconciled.
- Can the company serve it profitably? Revenue per unit must remain sensible against the real cost of delivering that unit, including expensive edge cases.
A metric that fails the first test creates budget anxiety. A metric that fails the second creates revenue leakage. A metric that fails the third creates disputes. A metric that fails the fourth can turn adoption into a financial liability.
The fourth test is where many software companies are weakest. They know average infrastructure spend, but not the cost of the specific unit they sell. Averages hide the difference between a lightweight customer and a tenant that triggers long-running jobs, premium models, repeated retries, heavy support, and unusual data retention.
A pricing model can look healthy at the company level while a fast-growing customer segment quietly destroys contribution margin.
Billing Events Need Stronger Guarantees Than Product Analytics
Many teams try to build billing from the same event stream they use for analytics. The temptation is understandable: the data already exists, the dashboard already shows usage, and adding an invoice calculation seems easy.
But analytics and billing have different standards of correctness.
Analytics can often tolerate sampling, delayed ingestion, evolving schemas, and approximate counts. A product team can still learn from a chart that is directionally right.
Billing cannot be “directionally right.”
A duplicated event charges a customer twice. A dropped event loses revenue. A changed definition can alter an invoice after the fact.
A billable event should therefore behave more like a ledger entry than a tracking pixel. It needs a stable identity, tenant context, timestamp, quantity, unit, source, and pricing-version reference. Retries must not create duplicates. Corrections should produce explicit adjustments rather than silently rewriting history. Late-arriving events need a defined accounting period. Backfills need rules. Contract changes need effective dates.
This is not overengineering. The moment a number becomes money, its lineage becomes part of the product.
There is also a customer-experience consequence. If the application shows usage, the customer will reasonably expect that view to match the invoice. When it does not, support teams become human reconciliation engines.
The cost of weak metering then appears twice: once as lost trust and again as operating expense.
Gross Margin Lives Inside the Request Path
For a traditional software product, the marginal cost of one more user may be small enough that teams can ignore it for a long time. That assumption is increasingly unsafe for products built on external APIs, large models, media processing, real-time data, or compute-heavy workflows.
Imagine an AI support product that charges per resolved conversation.
The customer sees one outcome. The vendor may incur several model calls, retrieval queries, tool invocations, safety checks, retries, logging operations, and occasional human escalation. Two conversations that produce the same invoice line can have radically different costs.
The financial question is not merely, “What did cloud cost this month?”
It is: “What did it cost to deliver the unit we promised to sell?”
That answer changes engineering decisions.
A larger model may cost more per call but reduce retries and human escalations. A smaller model may appear cheaper while increasing the total cost of a completed task. Aggressive caching may improve margin but weaken freshness. Longer context windows may improve quality for complex cases while making low-value requests unnecessarily expensive.
The correct optimization target is rarely the cheapest component. It is the best economic performance of the complete workflow.
This is why cost attribution should follow product entities that the business understands: customer, workspace, job, transaction, workflow, or completed outcome.
Infrastructure tags alone are not enough. They tell you where money was spent, not whether the spending created a valuable unit.
Growth Can Increase Revenue and Reduce Freedom at the Same Time
Software teams often assume that more usage is automatically good. Commercially, that depends on how quickly usage turns into collectible cash and how much cost arrives first.
The warning in Harvard Business Review’s analysis of how fast a company can afford to grow is that a profitable business can still run out of cash when growth consumes money faster than operations generate it. In software, the contract and billing design can widen or narrow that gap.
Consider an enterprise deal with a large annual value, monthly billing, sixty-day payment terms, a costly implementation, and a sales commission paid at signing.
The headline contract looks impressive.
The company may still fund months of delivery before receiving meaningful cash.
Now add usage-linked infrastructure costs. The customer can begin consuming compute immediately while the vendor waits to collect. Revenue, cash, and cost move on different clocks.
That does not mean every company should demand annual prepayment. It means payment timing is part of product economics, not an administrative detail.
Minimum commitments, prepaid credits, deposits, usage allowances, and overage terms are tools for distributing risk between customer and vendor. Each can improve one dimension while making another harder.
Annual prepayment improves cash but raises the buyer’s commitment. Pure pay-as-you-go lowers adoption friction but transfers more demand volatility to the vendor. A minimum commitment improves predictability but can create shelfware. A generous allowance makes bills easier to understand but may subsidize heavy users.
The goal is not to choose the contract that protects the vendor at any cost. It is to choose one whose cash timing matches the cost structure of the service.
AI Is Making Old Pricing Assumptions Expire
For years, per-seat pricing worked because software value often scaled with the number of people using the tool.
AI changes that relationship.
A small team can now ask software to perform work that once required many users. The number of seats can fall while the volume of work, customer value, and vendor cost all rise.
Charging only for access may underprice the product. Charging only for tokens may expose internal cost without expressing customer value.
McKinsey’s discussion of how software business models are changing in the AI era describes the movement toward consumption and units of work as AI products do more of the work themselves.
The technical implication is easy to miss: a company cannot monetize a unit of work that its product cannot define, count, explain, and economically support.
This is why many AI products are moving toward hybrid models.
A base commitment can pay for access, support, and reserved capacity. Included usage can make spending predictable. Overage can allow expansion. Outcome-based elements can align price with value where the outcome is sufficiently clear.
Hybrid pricing is not automatically better. It can also become a confusing stack of meters, thresholds, credits, and exceptions.
Complexity is justified only when it reflects a real difference in value or cost. Otherwise, it is just organizational uncertainty exported to the customer.
A Simple Example: The AI Support Agent
Assume a company sells an AI support agent.
If it charges per human support seat, it may punish its own success. The product helps the customer reduce the number of agents, so customer value rises while vendor revenue falls.
If it charges per token, measurement is easy and cost alignment improves. But customers do not buy tokens. They buy faster resolution, lower support expense, and better service.
Token pricing makes customers absorb implementation details they cannot fully control.
If the company charges per conversation, the unit is understandable, but not all conversations are equal. A password reset and a complex billing dispute may have very different costs and value.
If it charges per resolved case, the model moves closer to value.
Now the company must define resolution.
Does the case need to remain closed for twenty-four hours? What happens when the customer reopens it? What if the AI resolves the immediate issue but the satisfaction score is poor? What if the conversation is spam? What if a human takes over after most of the work is complete?
The pricing idea has become a product specification.
A sensible design might combine a platform fee with included resolved cases, transparent overage, and a clear definition of resolution.
But the important work is not choosing the final numbers.
It is building a shared definition that sales can promise, customers can understand, engineering can implement, finance can reconcile, and support can defend.
Write the Economic Contract Before the Sprint
Before implementation begins, create a one-page economic contract for the product.
Name the customer value event. Define the billable unit in plain language. Specify the system of record, the moment the event becomes final, and the rules for retries, reversals, refunds, late data, and contract changes.
Estimate the delivery cost not only at the average but under heavy and unusual usage.
Describe how the customer will see consumption before receiving an invoice. State how a disputed number will be reconstructed.
Then review that document with product, engineering, finance, sales, and customer success.
This meeting will surface conflicts that no pricing spreadsheet can reveal.
Sales may be promising a business outcome that engineering cannot measure. Engineering may be counting a technical event that customers do not associate with value. Finance may discover that payment terms create a cash gap. Customer success may know that the proposed metric will generate anxiety or encourage unhealthy behavior.
Finding those problems before launch is cheap.
Finding them after customers have signed contracts is a migration.
The Business Model Is Running in Production
Software companies like to separate technical architecture from commercial strategy.
Customers do not experience that separation.
They experience response times, limits, invoices, usage screens, renewal conversations, and the consequences of every rule encoded in the product.
A pricing model that cannot be measured cleanly will become a data problem.
A metric customers cannot predict will become a trust problem.
A unit whose cost is invisible will become a margin problem.
Payment terms that ignore delivery costs will become a cash problem.
The strongest products connect these layers deliberately.
Your billing model determines what you count. What you count determines what teams optimize. What teams optimize determines the product you become.
Pricing is not the number placed on top of software after the real work is finished.
It is one of the deepest architectural decisions the company will make.
Top comments (0)