There's another caveat to this, which is that even in places where usage-based pricing may be best, doing too much of it may lose the advantages.
An example from my experience: Datadog. It makes sense that we pay for usage, after all things like logging and metrics scale in wildly different ways from product to product, and charging flat rates or per-user rates doesn't factor this in well enough. The problem is that for a feature-complete Datadog deployment, there may be 10-20 axes of pricing – how much log data, how many unique metrics, how much of your logs do you want to index, and so on.
The problem comes with cost estimation. Because there are so many axes, we can't just take our size and figure out a cost estimate, we have to model out different scenarios. Does a traffic spike for us equal a logging spike? or Metrics? How does it impact second order pricing like log indexing or archival? Even when you know exactly how much, e.g. logging you generate, it's still all approximated modelling, and many teams won't have the necessary input numbers at the beginning anyway.
Stripe's usage-based pricing works well because it's so direct – it's just X% of revenue. Datadog's is a pain because there are many factors, all of which are quite far removed from revenue.
I understand that at some level this is required. They're pricing for compute and storage, essentially, and a cloud provider offering those wouldn't price them at a flat rate or per-user rate, but it always felt much harder than it needed to be. I'd almost have rather paid more, but a known amount.
However,
An example from my experience: Datadog. It makes sense that we pay for usage, after all things like logging and metrics scale in wildly different ways from product to product, and charging flat rates or per-user rates doesn't factor this in well enough. The problem is that for a feature-complete Datadog deployment, there may be 10-20 axes of pricing – how much log data, how many unique metrics, how much of your logs do you want to index, and so on.
The problem comes with cost estimation. Because there are so many axes, we can't just take our size and figure out a cost estimate, we have to model out different scenarios. Does a traffic spike for us equal a logging spike? or Metrics? How does it impact second order pricing like log indexing or archival? Even when you know exactly how much, e.g. logging you generate, it's still all approximated modelling, and many teams won't have the necessary input numbers at the beginning anyway.
Stripe's usage-based pricing works well because it's so direct – it's just X% of revenue. Datadog's is a pain because there are many factors, all of which are quite far removed from revenue.
I understand that at some level this is required. They're pricing for compute and storage, essentially, and a cloud provider offering those wouldn't price them at a flat rate or per-user rate, but it always felt much harder than it needed to be. I'd almost have rather paid more, but a known amount.
However,