Usage-based pricing is loved by devs. But has its own problems.
Ok, so first what are those problems?
Value metric:
- users don't understand your value metric
- even when they do, they cannot map it to their usage patterns.
Predictability and procurement:
- it is easier to predict the headcount than the usage
- per user pricing is obvious, everyone across the org understands it
But devs love usage-based pricing:
- it is "fair", you pay for what you use
- you can scale up/down as you need
It is great for a dev tool company:
- you align user adoption, the value created, and monetization
- as org-wide usage so does the invoice
But pulling it off is not as easy as you may think.
Choosing that value metric, packaging it, and presenting it is a struggle.
@Appsmith solved it in the following way:
- give people an option to go with a usage-based pricing
- but cap a per-user cost at $X a month
- it guarantees a better deal than a flat per-user pricing
- but gives you the predictability of a per-user pricing
Very interesting approach.