How to Price Software When You Can’t See Usage Yet

TL;DR Pricing software without usage data has a real answer, and it is not “wait for the meter.” Instrument first, price second is the right sequence, and it does not help the company that has to invoice this quarter. Both halves are answerable in order. Until the meter exists, price on bounded, observable, customer-verifiable units and refuse any commitment to a value metric you cannot count. Boundedness lives in the grant, not in the shape of the price, and a grant the product cannot enforce is a fence made of paper.

An enterprise buyer sends back the order form with one edit. They want the AI capability written in as unlimited. Your product has no telemetry on that capability, so you cannot count what this account would consume, cannot cap it, cannot true it up at renewal, and cannot walk into next year’s negotiation with a number either side would recognize. The deal is real, the quarter is real, and the instrumentation is a roadmap item somebody keeps deferring.

That order form is where pricing software without usage data stops being an abstract AI software pricing topic and becomes a decision with a signature under it.

The Question Behind Pricing Software Without Usage Data

A company in this position is asking two things at once. What can we charge today, on what we can already count? And what has to exist before we can charge differently?

Running them together produces the two failure shapes we see most: signing a consumption or outcome commitment the product cannot substantiate, or freezing the pricing decision entirely until an instrumentation project nobody has staffed delivers.

The sequence is instrument first, price second. That does not mean price nothing until the meter ships. Money can be attached to a unit you cannot yet observe, and companies do it. It is simply harder to transact: the buyer has less to verify, your team has less to defend, and the disputes arrive later rather than never. The difference between a pricing model and a value metric is what makes the two halves separable: the model is the rulebook that computes a price, the value metric is the unit that price attaches to. Hold a sound model today and change the unit later. Changing the unit is the expensive move, which is why it should not be made blind.

The more useful frame is that the metric you want and the metric you can currently support are often different units, and the distance between them is something to design rather than wait out. An intermediate unit can carry the price while the instrumentation that supports the real one is built, chosen so that the data it generates is the data the destination metric will need. That makes it a bridge rather than a placeholder. Most companies pick a metric and go, then react when it stops fitting. The alternative is to pick a strategy, which may be a sequence of metrics with a known order and a known destination, planned in advance rather than in response.

What You Can Price On Before the Meter Exists

Every metered software company was unmetered first. The interim architecture is a stage, not a compromise, and its job is boundedness and estimability rather than precision. A unit with the three properties below can carry money before you have a single event in a data warehouse.

Bounded

The grant has an edge: a named user, a site, a legal entity, an instance, a deployment, a device. Somewhere there is a number beyond which the customer has to come back and buy more.

Observable

Both parties can count it without telemetry, from artifacts already sitting in the customer’s own records. Headcount, locations, subsidiaries, environments.

Customer-Verifiable

The buyer can reconcile the count against an invoice without taking your word for the number. Verifiability is a trust property of the value metric, and it is the one that survives into the metered era unchanged.

The research base has held this position for a long time. Peer-reviewed economic theory on information goods finds that once administering usage-based billing carries any real cost, a fixed-fee option belongs in the pricing menu on its own merits, and pure metered pricing is not automatically the superior structure. Metering cost is part of the model choice rather than an obstacle in front of it.

The buyer side of that mirror points the same way. Peer-reviewed research on how enterprise buyers evaluate pricing models finds they prefer a predictable base they can budget and scale against, rather than exposure that moves with consumption they cannot forecast. Your visibility problem has a counterpart across the table.

Bounded and observable is a property class, not a recommendation of any particular unit. Which unit fits a given product depends on where that product injects value, and landing it is design judgment per company.

The Grant Is Words. The Product Is the Fence.

A bounded grant on paper bounds nothing if the product still serves whatever the customer can reach. The contract describes what a customer may do. The product delivers what a customer can do. When those two diverge, the contract is a fence made of paper standing in front of live exposure, and it stays that way until an engineer closes the gap.

Managing variability around the value metric you intend to launch is a product capability, not a clause. Enforcement points, allocation, account-level visibility into consumption, the ability to hold a limit and communicate it before a customer reaches it: none of that arrives in a redline. That is why settling this later, or on the fly, costs what it costs. Words can be amended in a redline. Product gearing cannot.

The test to run on your own agreements: for each entitlement you grant, name what enforces it. If the answer is only the paper, you have named your exposure.

Why the Billing System Comes Last

The most expensive sequencing error in this whole area is buying the entitlement or billing system first.

Purchasing infrastructure before deciding what to measure runs the sequence backwards, because the purchased system’s assumptions become silent constraints on every value metric decision that follows. You will not experience them as constraints. You will experience them as a series of strategies that keep almost working.

The analogy is an inventory system bought before anyone decided what needed tracking, one that turns out not to read barcodes. Two years later the company still cannot explain why every initiative depending on item-level visibility stalls at the same place. The constraint was purchased on day one, before the question it constrains was ever asked.

None of this is an argument against buying metering infrastructure. Metering is real infrastructure and you will need it. The argument is about order. The runtime stack, meter, billing engine, entitlement enforcement, exists to execute decisions, and it should never be in a position to shape them.

The Commitment to Refuse

One commitment should be refused outright before the meter exists: an unbounded grant with real marginal cost underneath it.

The risk in a flat or committed price has never lived in the shape of the price. It lives in the boundedness of the grant. A flat price over a bounded grant is sustainable by construction, because the worst case is defined at signature. A flat price over an unbounded grant is an open position whose survivability depends on facts nobody is currently measuring.

Generative AI serving costs are what put this on the agenda. LLM inference places genuine marginal cost under every interaction in a category built on the assumption that marginal cost was zero. An unlimited grant with no meter watching it reads as a generous commercial gesture and functions as an unpriced liability that expands with adoption. The failure pattern is public and recurring: products scale revenue impressively while gross margin runs the other way, and nobody catches it in time because the events that would have shown it were never captured. Our field guide to consumption pricing that backfired walks the cases where that architecture broke in public.

One adjacent trap deserves naming. Passing a model vendor’s per-token price through to your customer with a markup is cost-plus pricing under a consumption label. It is not value-based pricing, and it hands your margin ceiling to somebody else’s price list. It also hands the customer the variability, arguably the thing that scares them the most in transacting with you.

Instrumentation Is a Pricing Decision

Once you accept that the meter has to exist before the value metric can carry money, one consequence follows immediately. What you choose to observe determines which value metrics will ever be available to you.

Instrumentation designed by engineering alone tends to measure what is convenient to log: system events, request counts, whatever the framework emits by default. That produces a data set which can support billing and cannot support pricing, because what customers describe as valuable is rarely what the framework emits.

The instinct that corrects for it usually overshoots: meter everything, decide later. That is its own failure mode, and it is not free. Instrumentation adds work to every request it observes, and the storage and indexing cost of fine-grained event data climbs with the number of distinct things being counted rather than with the traffic alone. Engineering has a standard answer to that bill, which is to sample and aggregate, keeping the shape of the data and discarding the detail. Billing-grade data cannot take that treatment. An invoice has to be complete and defensible line by line, so the cost-control move available to observability is unavailable to pricing, and the detail that gets aggregated away to make the bill affordable is often the exact dimension a value metric needed.

Meter where value is injected. The value metric decision turns on three properties: the buyer can understand it without a sales explanation, the buyer can estimate it well enough to predict a bill, and it diverges from your cost structure rather than tracking it. A meter installed without those properties in view forecloses the right unit before anyone has evaluated it.

Candidates for that unit are easier to find outside your own telemetry than inside it. Value gets delivered in recognizable shapes, and those shapes repeat across markets that otherwise have nothing to do with each other. A category that charges for a resolved case, a completed transaction, a monitored asset, or a unit of throughput is describing a value-delivery pattern, not an industry quirk, and the analogous unit in your own product is usually sitting there once you go looking for the pattern rather than for a data field. This is the argument for pattern matching over data mining. A unit borrowed from a delivery pattern that already carries money somewhere has been tested against real buyers, real procurement, and real renewals before it ever meets yours. A unit chosen because it happened to be in the event stream has been tested by nobody. Reading those patterns across a wide enough body of pricing architectures is how the borrowing gets done with any confidence, and it is the part of the work that does not come out of your own logs.

Where the meter lands is specific to a product’s architecture and its customers, and it is engineering and pricing judgment made together. Naming that the decision exists, and that it belongs to both teams, is what keeps it from being settled silently at implementation time.

What the Meter Will and Will Not Tell You

Assume the instrumentation ships and the data starts arriving. Be precise about what you now hold.

You hold sensing. Usage patterns, adoption depth by capability, cost to serve per account, drift between what customers bought and what they use. That is real, and it permanently upgrades the quality of every pricing decision that follows.

What you do not hold is the answer. Realized usage under one price schedule cannot tell you what customers would have done under a schedule never offered, and peer-reviewed demand research on usage-based structures is explicit about that limit. Billing exhaust is also survivorship data: an invoice exists only because someone accepted a price, so the entire history is written by winners. Losses, collapsed quotes, and configurations procurement rejected never generate a record. We covered why that structure disqualifies billing data as decision evidence in its own piece.

The split that holds is always-on sensing, deliberate deciding. Instrumentation runs continuously. The decisions it informs stay governed and human, made by people accountable for the customer base the change lands on.

The Sequence, Run as a Test

Nothing above requires a project plan. It requires four answers about your own product.

1. If your serving costs doubled next quarter, which part of your architecture would see it first, and how long after the fact?
2. Which grants in your current agreements are unbounded, and what enforces the ones that are bounded? Paper alone is not an answer.
3. If you shipped a meter this month, which value metric would it make available, and did anyone on the pricing side choose it?
4. When the new model is ready, does it go to new business first, or does it land on the installed base the same quarter the telemetry arrives?

The last one has a settled answer: new business first, then customer transition. A controlled rollout validates a decision inside a real commitment, while a buyer-initiated pilot defers the commitment and stalls in committee. When those four answers are uncomfortable in a specific way you can name, that is usually the moment to bring in someone who has sequenced it before, which is what our talk to an expert form exists for.

Every company in this position feels behind. Almost none of them are.

The feeling comes from a bad comparison. You are looking at your own instrumentation, which is partial, and at a competitor’s pricing page, which is finished. One of those is evidence of what a company can do and the other is a claim about what it sells, and they are not the same artifact. A published consumption model tells you a vendor decided to charge that way. It tells you nothing about whether their product can count it, cap it, or defend the number when a customer disputes an invoice.

Measure against the standard instead of the fashion, and the ranking changes. The standard is whether the price is defensible and the grant is enforceable. By that measure, a company still pricing on bounded units it can actually count is in better shape than one that shipped an unbounded consumption commitment its product cannot substantiate, and the second company is the one whose pricing page looks current. Moving early on a unit you cannot enforce is not being ahead. It is carrying an exposure that has not surfaced yet.

Being genuinely behind is narrower than the anxiety suggests: the metric question has never been asked, so the meter gets specified by whoever files the ticket, and the answer arrives as a constraint rather than a decision. A company that knows which unit it is heading toward, and why the current one is a bridge to it, is running the sequence in the right order even if the telemetry ships next year.

Describe where your product sits on that path and what commitment is currently in front of you, and a pricing expert will read it and reply.

FAQs