Usage-based pricing isn't always best
There&#x27;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.<p>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&#x27;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.<p>The problem comes with cost estimation. Because there are so many axes, we can&#x27;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&#x27;s still all approximated modelling, and many teams won&#x27;t have the necessary input numbers at the beginning anyway.<p>Stripe&#x27;s usage-based pricing works well because it&#x27;s so direct – it&#x27;s <i>just</i> X% of  revenue. Datadog&#x27;s is a pain because there are many factors, all of which are quite far removed from revenue.<p>I understand that at some level this is required. They&#x27;re pricing for compute and storage, essentially, and a cloud provider offering those wouldn&#x27;t price them at a flat rate or per-user rate, but it always felt much harder than it needed to be. I&#x27;d almost have rather paid more, but a known amount.<p>However,