Completely agree with this thesis. At Now4real (a group chat SaaS for websites), we made the deliberate choice to price our AI-based moderation per 1,000 analyzed messages, completely abstracting away the concept of tokens. Our customers care about keeping their communities safe, not about doing the math on our underlying compute costs. By pricing based on the actual unit of value delivered—the message—we eliminate friction, keep our pricing predictable, and ensure we aren't confusing our application's value with an LLM provider's cost structure.
Interesting, but the example of Github copilot pro must not be forgotten. It may be said that copilot was selling access to models, but if we’re putting it on that way, then every AI app is selling access to models so let’s say they were selling code. Initially they priced per request, i.e. per feature (proxied) that the dev wanted to implement. But that totally backfired because of the unpredictability of the workflow the agent had to do. I believe that the winners will be those who are capable of reducing the marginal cost of each new / unpredicted workflow, and at that point they can price by outcome. Otherwise the customer risks paying a lot of money for nothing (as the vendor must protect from unpredictability), or the vendor will blow up like Github
I’d add one qualification: outcomes only work as a pricing unit when both sides can agree on attribution.
For many workflow SaaS companies, the cleaner model may be a platform fee + usage tied to a recognizable unit of work: a workflow completed, case processed, account researched, claim reviewed, etc.
That gives procurement something measurable and forecastable without forcing the vendor to price against an outcome it doesn’t fully control. The task/workflow may often be a better commercial unit than the ultimate outcome.
Completely agree with this thesis. At Now4real (a group chat SaaS for websites), we made the deliberate choice to price our AI-based moderation per 1,000 analyzed messages, completely abstracting away the concept of tokens. Our customers care about keeping their communities safe, not about doing the math on our underlying compute costs. By pricing based on the actual unit of value delivered—the message—we eliminate friction, keep our pricing predictable, and ensure we aren't confusing our application's value with an LLM provider's cost structure.
I am working on a SaaS now and am trying to figure out how to implement this. This comment on this article is great!
Interesting, but the example of Github copilot pro must not be forgotten. It may be said that copilot was selling access to models, but if we’re putting it on that way, then every AI app is selling access to models so let’s say they were selling code. Initially they priced per request, i.e. per feature (proxied) that the dev wanted to implement. But that totally backfired because of the unpredictability of the workflow the agent had to do. I believe that the winners will be those who are capable of reducing the marginal cost of each new / unpredicted workflow, and at that point they can price by outcome. Otherwise the customer risks paying a lot of money for nothing (as the vendor must protect from unpredictability), or the vendor will blow up like Github
I’d add one qualification: outcomes only work as a pricing unit when both sides can agree on attribution.
For many workflow SaaS companies, the cleaner model may be a platform fee + usage tied to a recognizable unit of work: a workflow completed, case processed, account researched, claim reviewed, etc.
That gives procurement something measurable and forecastable without forcing the vendor to price against an outcome it doesn’t fully control. The task/workflow may often be a better commercial unit than the ultimate outcome.