alt Hacker NewsSome products (especially infrastructure) still bill based on (outdated and often irrelevant) core counts and memory count. A few years ago I talked to a seller of a PDF library/toolkit who wanted to know my production and staging core count before they would quote me a price. Explaining to them that it runs in a serverless function on-demand was fun, especially because they would say things like, "well, what's your average?" I would often reply and say my average is defined by a function where you take the number of active users (which itself is highly elastic) and calculate for average runtime at 4 cores per user for approximately 50 ms per page (which page count is highly elastic too) and sum to get "average core use per month". Needless to say it was like pushing a rope.
More common now with SaaS seems to be employee count or some other poor proxy measurement for usage. I love actual usage based billing, but some of the proxies people pick are ridiculous. Like, if I have 5 seats or 500 employees, but 2 users spend 6 hours a day in the software and then 10 others maybe look at it once a quarter, paying the same for those is absurd and is not usage-based billing at all.
Replies
Usage-based pricing makes sense when you’re buying infrastructure products. For (most?) other things, the price is based on value, not material cost.
The cost of that PDF generation might as well round up to zero, but developing the tech cost multiple man-years of work. How do you price that “objectively” unless you’re given a breakdown of the company R&D expenses, operation costs and margins. That is not a reasonable request. Either you’re happy paying $X because it solves your problem and brings equivalent value to your business, or you’re not.
I do agree seat-based pricing is often ridiculous, but that’s a problem for the free market to solve. Alternatives usually pop up given enough demand.
What you described is likely usage-based, in the sense that the (presumably cloud) vendor usually has to reserve a certain amount of resources per user, “just in case”, because they don’t know / can’t predict your activity pattern. Same reason VMs are still charged for when started but idle: they reserve their CPUs.
What people really want, when they say “usage-based billing”, is outcome-based billing. They want to get charged money whenever they hit the button in your software that makes them money (or, for a cost-center, saves them money.)
Think of e.g. tax prep companies. (For the average Joe employee), they don’t charge you money up-front; instead, they take a part of the net-positive return they fully expect to find you. They make you happy, then take a slice of your happiness at the exact point that they’re making you happy. Outcome-based billing.
Yes. There’s nothing more obnoxious to me than products like Figma where my company has a limited number of full licenses. They are super stingy with what my account type can do, so the 2 times per year when I need to get involved inside a Figma document or even a FigJam board I have to go begging for someone else’s license, but it would be way too costly to pay as much per seat for the entire company as we pay for our designers, for whom that’s obviously a core tool.
I spend a lot of time on pricing and packaging of SaaS software and the challenge is real. Everybody says they want simple pricing, which often aligns to seats or MAU - but then they want usage-based pricing, but then they're concerned about unpredictable costs and spiky usage.
Unfortunately, there's no such thing as a free lunch - you can have simple and predictable but you will have some users that you pay for that aren't getting value. You can have usage-based billing, but then you run the risk that anyone who uses an antipattern for the product will suddenly cost you a ton (or consume all of their allocated quota and be dead in the water, which is differently bad).
The more flexibility you offer, the more complexity you're putting onto customers and sales teams to understand what's the best way for them to consume the software.
There's also a lot of market pressure to "follow the crowd" - even if you have an option that is (in your mind) more customer friendly/favorable, if you are structuring your pricing differently than the competition, there will be customers who are concerned that they're not getting "a good deal" or concerned that the structure will end up being less favorable to them over time (after all, why does everybody ELSE do it this other way?). Sales reps also prefer pricing strategies that are at least structurally consistent with other products on the market, because it makes their lives easier.
Similarly, it's very difficult to change pricing nad packaging later on - changing price is relatively simple, but changing units of billing or retiring an old offering can be an extremely difficult task.
(disclaimer: these are just my own opinions, everything is hard)