Which tier is paying for that feature?

You set your tiers on value, and you were right to, what a customer will pay is a question about what the thing is worth to them, and costing it up and adding a margin is how commodity businesses price. When costs rose this year you raised prices, which was the sensible response, and if you asked finance they would tell you blended gross margin is healthy. All three of those are true, and none of them says anything about the tail.

Every decision about what goes in which tier rests on an implicit answer to one question: what does this feature cost when the customers on that tier use it. Not what the feature costs in total, and not what a customer costs to serve on average, but how much of a feature's cost is driven by the usage of each tier. Starter accounts for 62 per cent of it, Pro for 26, Enterprise for 12. Cost per feature per tier is a unit economic, and a narrower one than most businesses attempt.

Almost nobody has that number, the decisions get made anyway, because a packaging decision cannot wait for a measurement, so people proceed on the assumption that the split roughly follows the price. The cheap tier uses less, the expensive tier uses more, and the tiers are therefore roughly self-funding. That assumption used to be safe.

It worked while the cost gap between any two features was small enough to ignore. Features shared the same infrastructure, and the difference between the cheapest and the dearest thing in your product was a rounding error against the cost of running the platform at all.

An inference-backed feature is not a rounding error, it can cost more per use than everything else in the tier combined, which means a single feature can now determine whether a tier is profitable.

Consumption inside a tier stopped being uniform at the same time, two customers on the same plan used to cost about the same to serve, because the way they consumed was roughly the same, and the cost was stable. However, when the feature they are using bills by the token, the heavy user and the light user are different businesses to you, and they are paying the same price.

A price rise moves the line, it does not remove the customers sitting past it. You cannot price your way out of a distribution you cannot see.

Raising prices to cover a higher average cost per customer is the standard response and it does work, in the sense that it moves the point at which a customer stops being profitable further out. What it does not do is remove the customers already past that point, because the problem is the shape of the distribution rather than where its centre sits. You can move the line as often as you like, without knowing what is past it you are guessing at how far.

Traditionally the argument against everything above is that cost per feature is a fiction, features are not separable. They share compute, database, observability, the gateway, the platform underneath all of it, so any figure attached to a single feature is an allocation choice, not a measurement.

That argument was correct for a long time, which is why it hardened into something everyone knows. A decade of shared infrastructure and little usage telemetry made 'you cannot cost a feature' a fair inference rather than a lazy one. It is worth testing whether it still holds, because two things have to be true and both now are.

The first is usage resolved by tier, and it has to be counted in the unit you are billed in, particularly when it comes to AI. This is where most attempts fail, and they fail quietly, counting calls per tier gives you a total, not a cost share: if Starter makes 70 per cent of the calls but uses few tokens, Starter does not necessarily carry 70 per cent of the cost. Output tokens, GB-hours, rows scanned, requests weighted by size. The unit has to be the one the invoice is calculated on, and for AI providers that unit arrives at token level already.

The second is cost resolved to the components a feature is made of, which is what attribution produces. An assisted call is not one cost, it is inference, retrieval, the application, the database, storage and the logging pipeline, each billed separately and each traceable to what caused it. OPTIMAZE derives that from how resources, accounts, services and metadata already relate, and ingests token-level AI cost directly from the provider APIs, so the components arrive priced rather than estimated. Neither half is exotic, together they produce the number.

Take an AI summarisation feature costing $40,000 a month across every component. Inference and retrieval account for $32,000 of that, the remaining $8,000 is the application, database and logging capacity it runs on.

Measure output tokens by tier and the split comes back at 62 per cent Starter, 26 per cent Pro, 12 per cent Enterprise. Applied to the variable half, Starter is consuming $19,840 of it a month, across 4,000 customers paying $30.

So one feature is consuming $4.96 of a $30 subscription. Sixteen per cent of that tier's price, before anything else in the product is accounted for.

Show Image

Nothing about that is visible from a healthy blended margin, and nothing about it is fixed by moving Starter to $35. Raising the price covers the average Starter customer. The Starter customer at the top of the usage distribution might be consuming four times the median, and they are the reason the tier's margin is not what the average says it is.

That figure is a contribution number. It covers what moves with usage, and it is the right instrument for a packaging decision: whether to move a feature to a higher tier, cap it at the lower ones, or reprice the tier around it, every part of that number is measured.

The fully loaded version includes the capacity underneath. Metering resolves that half as well, through CPU-seconds and memory-byte-seconds per workload, query counts and rows scanned per service, spans and log lines per service, so those parts reconcile to the bill instead of being apportioned by assumption. Measured that way, Starter's share of the capacity half comes back at 45 per cent, not the 62 the tokens gave, which is $3,600. The fully loaded figure is $23,440, whereas the contribution figure is $19,840.

That second number answers a different question, which is whether the feature should exist at all. One caution goes with it, and it is the same caution the avocado makes: consumption and recoverability are not the same thing. Removing a feature stops the inference immediately. The database cluster it shared is sized for peak, and it does not shrink because one feature left.

A pricing lead will say that none of this sets a price: price is what a customer will pay, determined by the value they get and what the alternatives cost them, and a business that prices off its cost base has stopped competing on value. That is correct, and it is how the tiers above should have been set.

Value-based pricing still needs a floor. When the price that value analysis produces lands below what serving that tier costs, four responses exist and all four are legitimate. Do not sell it, sell it at a higher price and accept the lower volume that follows, or change the pricing model, metering the feature and capping the allowance included in the tier. Knowingly sell below break-even because the tier feeds something else: it is the top of the funnel, it produces the case studies, it converts upward at a rate that pays for itself elsewhere.

Every one of those is a defensible decision, yet none of them can be made without knowing where the floor is, and a business that has never calculated it is not choosing the fourth option. It is in the fourth position without having chosen anything.

That is the difference this number makes, not a cheaper product, and not a different price. A decision that was being made by default becomes one somebody made.

If this sounds like something you or your business needs, get in contact with our sales team.

In short

• Cost per feature per tier is the share of a feature's cost driven by each tier's usage. It is not the cost of a feature, and it is not the cost of a customer.

• Usage has to be counted in the unit the invoice is calculated on. Counting calls per tier gives a total rather than a cost share, because a tier making most of the calls may be using few tokens.

• Cost has to be resolved to the components a feature is made of, since an assisted call carries inference, retrieval, application, database, storage and logging, each billed separately.

• The contribution figure covers what moves with usage and answers a packaging decision: move the feature to a higher tier, cap it at the lower ones, reprice the tier around it, or meter the feature and cap the allowance included in the tier.

• The fully loaded figure adds metered platform consumption and answers whether the feature should exist at all, with the caution that what a feature consumes and what ending it would recover are different amounts.

• Value sets the price and cost sets the floor. Selling below the floor is a legitimate strategy and an expensive accident, and the only difference between them is whether anybody worked out where the floor was.