Three Ways to Sell the Same Software - Nicolo's Notes

Skip to content

Three Ways to Sell the Same Software

09 Aug 2026·6 min read

An AI support agent, the kind that answers customer questions in a chat window and hands over to a human when it gets stuck, can be sold in three very different ways. Say $500 a month for access, $1 for every conversation it handles, or $5 only when the customer's problem is actually resolved. The software underneath could be identical in all three cases. What differs is what the vendor is on the hook for, and the chosen pricing model is one of the clearest expressions of that. A subscription sells access. Usage pricing sells activity. Outcome pricing sells a result, or at least puts some of the vendor's own revenue at risk against one. In practice the lines blur, and products often use more than one at a time. What has changed recently is that software now does enough of the job for the third to be a serious option at all.

Illustrative pricing models

It is worth being precise about what a price does here. The customer gets some value from the result, the vendor incurs some cost to deliver it, and the gap between the two is the economic surplus: the value the transaction creates. The price is the line drawn through that gap, deciding how much of the surplus each side keeps. This is basic economics, but worth keeping in mind. Importantly, when holding value and cost fixed, moving the line does not make the gap any wider; whatever one side keeps, the other does not. That is usually only true in the short term, though. Over a longer horizon the pricing model shapes how much a product gets used and what the vendor is incentivised to improve, which changes the size of the gap itself. What each pricing model really decides is how that line behaves: whether it sits still regardless of what the customer gets, moves with how much they use, or moves with a contractually defined result. That is also what decides which side carries the risk if the value never appears at all.

Starting with the line that sits still. As SaaS took hold the subscription became the industry standard, and for good reason: it is a genuinely good arrangement in a lot of ways. A flat fee gives the customer a number they can budget against and removes the need to weigh up whether each individual use was worth it, which is how a product becomes sticky rather than a recurring decision. Research in consumer services has found that people sometimes choose flat rates even when metering would cost them less, partly for the convenience and partly as insurance against an unexpectedly high bill.[1] The vendor carries the risk that a customer uses the product far more heavily than expected. The customer carries the risk that access produces nothing at all.

Because the price does not move, how much value the customer ends up keeping depends entirely on how much they get out of the product. A customer who gets a great deal of value out of the product keeps a large surplus. A customer who gets very little value pays exactly the same and keeps almost no surplus. That is what a subscription is really saying. Here is the tool, we will keep it available and working, and what you achieve with it is up to you. That was a fair reflection of who was doing what: the software supplied the capability, the customer did the work.

Flat subscription pricing is easiest to sustain in cases where serving a heavy customer costs the vendor little more than serving a light one, in other words when marginal cost is minimal. AI has been making these cases rarer: LLM inference introduces material per-task compute costs, so a heavy user can cost many times what a light one does, something I wrote about here.

One response to this is usage pricing, where the bill follows activity. It suits products whose marginal cost rises materially with activity, and it suits customers too: a small buyer can start small, and the bill contracts when demand falls. Going back to the line, it now moves rather than sitting still, but it moves with activity. The customer wants their problem solved; the vendor is paid for the attempt. The surplus is spread more evenly across customers than under a flat fee, since heavy users now pay for what they take, but the bill still tracks the work done rather than the result it produced.

There is a tension in that. Holding the price per unit constant, a vendor's revenue falls if the user reaches the same result with fewer billable units. Competition, retention, and the fact that fewer units also mean lower costs to serve may all outweigh that, but the meter itself does not strictly reward the vendor for efficiency.

One way to fix that is to stop metering the work and meter the result instead. Returning to the customer support example, under outcome pricing the vendor is paid only when the customer's problem is resolved, so a conversation that goes nowhere still costs money to process and earns the vendor nothing. That...