Per-seat pricing is off the table now
github.com
github.com
We do per metric pricing and « per-seat » as well, we built Lago for pricing flexibility. This post is more around pricing for the downturn, than about our product.
If you have specific feedback, because it is still perceived as self promotional, we are genuinely all ears. Thanks!
Presumably even if you support per seat pricing, thats not your main value add since SaaSs can quite easily implement per seat themselves.
If your software improves the productivity in your customer in a per-employee basis, of course you should still do per-seat pricing. That your customer has 10 employees using it instead of 100 before means your customer is actually getting 10x as less value from your software, and your pricing power is 10x less.
If you try to hack around this by changing to per interaction, or per thousand pageviews, this is equivalent to essentially raising your price. In other words, either you were underpricing to begin with in the previous economic boom, or your total profits will suffer if you move from per-seat pricing because then your costs are higher than optimal.
Now of course, if you provide value that is not on a per-employee basis, they by all means move off of per-seat pricing. But in that case why were you doing per-seat to begin with?
With the correction, a more thorough approach might be necessary.
Your own users.
I get it, it’s not a charity. But internally, I’ve had to lock down marketing from using any of the marketing features because we can’t afford them. And this is “re-marketing” effective, marketing to our existing user base.
While it might be a great way for intercom to extract $$ from the big end of town. It’s created an internal disincentive to actually utilise their product.
The whole sign up process was pretty painful too, had to go through sales, couldn’t just sign up and work out what we needed. Had to go on an annual contract.
Primarily chose it due to positive previous experiences, and the product is good. But in hindsight, we should have explored alternatives more thoroughly.
The other missed opportunity is that we’d have moved our entire email re engagement journey from Drip to Intercom, but not at the rates they charge. We’re better off running both tools.
Mind you, this is all just speculation.
And charging for a metric optimizes against using that metric.
One of the fundamentals of economics is that ownership tends to incentivise improvement. If you license something in perpetuity, you more than likely won't be doing the upkeep and improvement yourself. By renting, cash flow goes to the company doing the work and maintenance, and they can appropriately prioritize and fix issues, develop the product, etc.
Compared to SaaS, it's more difficult to develop and maintain on-prem, single purchase software for clients. You don't get to control the deployment or the operational conditions as easily, even if you do get to make certain mandates. It's a more distributed problem.
Perpetually licensed software also has to be priced higher, pushing lots of businesses and individuals out of the market entirely. Lots of customers never get served, and thus lots of money gets left on the table.
If you don't bring value to a company, they won't hire your product to do the job. It also makes it theoretically easier to switch to a competitor if paying for short term contracts.
How is it "rent-seeking" to have an optimal pricing model? https://en.wikipedia.org/wiki/Rent-seeking
The optimal pricing model will charge as close to $X without going over.
Even if charging $1/10th x would be wildly profitable.
Perhaps the term “price gouging” would be better.
per user pricing always seems like a heuristic for how much you think a company can pay rather than getting them to pay for what they use. it subsidizes small companies and then ratchets up costs as they grow, which i guess is good for your business but sure feels like a dark pattern to me.
GitHub had tiers based on number of repos years ago, but people then put you their repos together to lower their bills.
AWS has per-usage pricing and people regularly are surprised by their bills, making if tricky - not all Saas can do it
Sure, I don't know what their primary driver of scale is for a customer. Maybe it is users for all I know; I just know that for many businesses user is not.
> GitHub had tiers based on number of repos years ago, but people then put you their repos together to lower their bills.
Repo is just another heuristic. I could create hundreds/thousands of repos before I (likely) match the cost of nixpkgs or crates.
Also, what you bill on will inform behavior. In the original article, there's the implication that people will share logins to reduce cost and with per-repo pricing you get people consolidating repos. In both cases, these behaviors reduce customer cost without reducing your cost, so now your product has effectively had its price cut. You could go the Oracle route and mandate audits to combat this, but that's going to torch your good will. Better to just bill on what drives cost.
Not everyone can have a pricing like Snowflake’s. And you’d be surprised by the number of customers that want a fixed « all inclusive » pricing for peace of mind.
Everyone is running around storing databases full of passwords, and for what? So they can put "CALL" on the Enterprise tier.