We 100% agree with you. Actually the first tagline of Lago was "billing for product led SaaS", the wording was a bit confusing, but our thoughts were:
(i) "pure usage based pricing" models (like Snowflake's) aren't going to be the main standard for SaaS, for the reasons you mentioned, the main being predictability (for the merchant and the end-user). Cash collection is also a big pain: if you collect cash after the consumption, the dispute rate can be high.
(ii) However pricings will increasingly incorporate "usage dimensions" (monthly active rows, number of emails, GB used, etc) and this trend is spreading very fast (3 out of 5 SaaS according to the latest OpenView report).
It can take many forms: Annual subscriptions including a monthly base usage and/or prepaid credits based on consumption, and/or an amount of payments processed, etc
This is what we lived at Qonto.com and solved for, for 4 years, and you woudn't think of it at a "usage based player" though, we rather had "usage subscriptions" : https://qonto.com/fr/pricing
All the possible combinations make the billing very hard to maintain and iterate on, and this is why we built Lago.
All this to say, we 100% agree with you that not all companies should choose a "full usage based pricing" but find a balance or at least iterate between "subscriptions/fixed amount" and "usage based".
(i) "pure usage based pricing" models (like Snowflake's) aren't going to be the main standard for SaaS, for the reasons you mentioned, the main being predictability (for the merchant and the end-user). Cash collection is also a big pain: if you collect cash after the consumption, the dispute rate can be high. (ii) However pricings will increasingly incorporate "usage dimensions" (monthly active rows, number of emails, GB used, etc) and this trend is spreading very fast (3 out of 5 SaaS according to the latest OpenView report). It can take many forms: Annual subscriptions including a monthly base usage and/or prepaid credits based on consumption, and/or an amount of payments processed, etc This is what we lived at Qonto.com and solved for, for 4 years, and you woudn't think of it at a "usage based player" though, we rather had "usage subscriptions" : https://qonto.com/fr/pricing All the possible combinations make the billing very hard to maintain and iterate on, and this is why we built Lago. All this to say, we 100% agree with you that not all companies should choose a "full usage based pricing" but find a balance or at least iterate between "subscriptions/fixed amount" and "usage based".