
Maintenance
Part of Revenue model choice: the four questions that actually decide it
Revenue models framework: the 2027 review
A revenue models framework that eliminates rather than selects: four constraints on the buyer's side that rule out most charging shapes before you choose.
Most discussions about how to charge are held as though the choice were free. It is not. By the time you are choosing, four things about your buyer and your evidence have already ruled out most of the options, and the useful framework is the one that finds those four before anyone argues about preferences.
This page is about elimination rather than selection. Work through the constraints, see what survives, and the remaining choice is usually between two candidates rather than eight.
What to take away
- The buyer's approval process rules out more revenue models than your strategy ever will.
- Somebody carries the risk of the thing not working. Your model decides who, and it should be a decision rather than an accident.
- You cannot charge for what you cannot record. Metering is a constraint on the model, not an implementation detail after it.
Constraint one: how the money gets approved on the other side
Money leaves a buyer through a specific door, and each door has its own rules.
A one-off purchase from a capital budget is approved once, defended once, then forgotten. A recurring charge sits in an operating budget that someone reviews and can cut.
A per-transaction charge often lives inside the cost of what the buyer sells, so it is compared against their own margin, not your competitors. Discretionary personal spending needs no approval and has a much lower ceiling.
If your buyer only has capital budget this year, a monthly access fee is not a pricing problem. It is an unsignable contract. Ask which door the money comes through before you decide what shape to ask for.
If their operating budget is annual and yours is the only line that grows every quarter, you will be the line that gets examined. Ask the person who signs, not the person you have been talking to.
Constraint two: how long before the buyer can tell it worked
Every offer has a lag between payment and proof. Somebody carries the risk inside that lag.
Charge in advance and the buyer carries it, which they will accept only if the risk is small, the reputation is established, or the alternative is worse. Charge on delivery and you split it. Charge on a verified result and you carry it, along with an attribution argument you may not win.
The framework question is not "what feels fair". It is: who is best placed to bear this risk, and are they being compensated for it? A long proof lag with payment up front needs something to close the gap: a pilot, a shorter first term, a break clause, a milestone.
Who should carry a risk and what it costs to move it is the standing question in MIT's entrepreneurial finance course. A short proof lag makes up-front payment easy and makes outcome pricing a needlessly expensive way to charge for something obvious.
Constraint three: what you can observe and defend
You can only charge for events you can record. Not estimate: record, in a form that survives a customer disagreeing with you six months later.
Many usage models are designed past the first test and fail the third, and every dispute after that is settled in the customer's favor because the alternative is losing them. What each side is obliged to prove is read off the agreement, which is the ordinary rule in a claim for breach of contract.
This constraint also rules things in. Where you already hold a clean record of something the customer cares about, you have a candidate billing metric that costs you nothing to introduce. The pricing architecture guide covers what makes a metric worth keeping once you have a shortlist of them.
Constraint four: who stands between you and the money
Almost nobody sells with nothing in the middle. A channel, a platform, a distributor, an intermediary, or the employer of the person using the thing, each takes a share and imposes rules.
Two effects, and the second gets missed. The obvious one is the cut: money removed before you see it, so revenue per unit is not what your price says.
The less obvious effect: the intermediary's rules constrain your model shape. What can be billed, on what schedule, with what refund terms, and whether you may contact the customer at all are decided by someone else. They can change.
Where an intermediary sits in the middle, write down what they take, what they permit, and how much notice you would get if either changed. A model that only works under the current rules of a party you do not control is a model with an expiry date you cannot see.
Working the four in order
| Ask | What it tells you | What it usually rules out |
|---|---|---|
| Which budget door does the money come through | The shape a signature is possible for | Recurring charges to capital-only buyers, and large one-off asks to operating budgets |
| How long until the buyer can tell it worked | Who should carry the lag | Payment fully in advance where proof is slow and you are unknown |
| What can you record and defend | Which metrics are real candidates | Usage and outcome models with no defensible record |
| Who is in the middle | Your actual revenue per unit, and whose rules apply | Anything that depends on a permission you do not hold |
Run these before the model conversation, not during it. A team that starts from "should we be subscription" will spend a week on a question that constraint one had already answered.
When two constraints conflict
They often do. The buyer's budget wants an annual charge; your evidence supports per-use. The proof lag says charge later; your cash position says charge now.
Pick the constraint hardest to move and satisfy it properly, and do not split the difference into something incoherent.
Buy relief on the other with a specific term: a deposit against a long proof lag, a committed minimum against an unpredictable usage bill, a short first term against an unproven claim.
Those are trades. A trade you made deliberately can be revisited, but a compromise nobody named cannot.
Write the assumptions down beside the model
Date the page. Each of those statements can stop being true without an announcement, so when your model misbehaves, reread the four and find which one moved. That is the fastest diagnosis.
The same discipline for model choice generally appears in the business model types framework, and what the four choices then do to your cost side is the subject of unit economics.
Common questions
What if we have no buyers yet?
Then constraints one and two are hypotheses, and they should be labeled as such. Answer them from conversations with people who would sign, not from what similar companies appear to do, since you cannot see their approval process either.
Does this framework pick a price?
No. It narrows the shape. The number is a separate decision with its own inputs, and picking a number before the shape is settled means doing the work twice.
How often should the four be re-checked?
When something structural moves: a new buyer type, a new intermediary, a change in what you can record. A calendar review mostly produces changes nobody needed, which is also why the dated assumption page is worth more than a scheduled meeting.
Can we start with one model and switch later?
Yes. Switching costs sit mostly in contracts you already signed, so if you expect change, keep initial terms short and write the change rule into the agreement while you still have room to ask for it.
When a switch changes what you sell rather than how you charge, it belongs with the decisions in the business model types overview.







