Hacker News new | past | comments | ask | show | jobs | submit login
Per-seat pricing is off the table now (github.com/getlago)
33 points by romainhuet on Nov 25, 2022 | hide | past | favorite | 26 comments

Disclosure: this article is written by a company that specializes in per-metric pricing, and so the entire article is likely content marketing.

Hi! I work at Lago and co-wrote this article.

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!

The points you make can be fine, even if it is content marketing. Its just useful to point it out as such since the conclusions can be affected by the marketing goal.

Presumably even if you support per seat pricing, thats not your main value add since SaaSs can quite easily implement per seat themselves.

This analysis has the hidden assumption, which is that a customer that is feeling pain and doing layoffs is still getting the same (or higher) ROI from your software.

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?

I agree with you, actually one underlying hypothesis of this post is: Lots of companies shouldn’t have priced « per-seat » in the first place. But in a bull market, the teams were growing insanely and this pricing was easy to understand, it became a « by default » pricing in a lot of cases.

With the correction, a more thorough approach might be necessary.

Recently put intercom in place. Not only do you pay per seat (for support, and for ‘engage’ - marketing) but every single engage feature is effective CPM based. “People Reached” is charged at $125 per 1000 users.

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.

FWIW, I suspect intercom will become more customer friendly again, as they abandon their quixotic quest to alienate their small users in pursuit of enterprise ones.

That’d be nice. But why do you think they will?

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.

They changed their CEO back to the original founder recently. My understanding (from the outside) is that the replacement CEO was super focused on enterprise, whereas the founder-CEO was much more focused on smaller businesses and product led growth.

Mind you, this is all just speculation.

My favorite take on pricing ever is "Index to your Customers' Revenue Growth" (fourth card on this page) https://www.screenshotessays.com/browse. Basically saying that if your cost grows with your customers' revenue or some first derivative of that then you will be set for life.

A lot of people complain with SaaS that take a cut on revenue, when it’s not justified. For instance, if you are a payment processor, it makes sense to price based on the volume of transaction (your risk/work increases with the volume of transaction). But if you’re a « pure » SaaS, like a Sales commission software, would it make sense to take a cut on the amount of commission you manage?

Whenever you charge based on "value" rather than on based on cost of providing a service, you risk being undercut by a competitor.

Per-seat pricing is easy to budget for because it’s directly tied to headcount. Headcount is something non-technical people in finance and procurement understand. Be prepared for your sales team to be spending a lot more time explaining your pricing model if you decide to price based on some other metric.

“Value capture” means rent-seeking.

And charging for a metric optimizes against using that metric.

Of course. Much of the economy runs on "rent-seeking".

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.

Value first, money comes after. I do agree with your comment!

> “Value capture” means rent-seeking.

How is it "rent-seeking" to have an optimal pricing model? https://en.wikipedia.org/wiki/Rent-seeking

How is it not? You are trying to increase your profits without producing additional value.

Let’s assume the device or saas replaces something that cost $X per whatever.

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.

Wasn't this already on the front page earlier this week?

just charge for consumption. and if your users wants to pre-pay for fixed amounts of consumption then give them that opportunity.

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.

What's consumption in case of Slack? Number of messages? Storage+CPU usage+bandwidth?

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

> What's consumption in case of Slack? Number of messages? Storage+CPU usage+bandwidth?

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.

I work at Lago. Although we are perfect for usage based billing, I agree that « pure usage based billing pricing » doesn’t fit all products.

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.

Even darker when startups are encouraged by SaaS pricing to avoid SSO like the plague.

Everyone is running around storing databases full of passwords, and for what? So they can put "CALL" on the Enterprise tier.

At least, they should find another revenue streams. Some companies only price per seat while their customers share seats with a shared-password tool. We all do this. Having addons and other revenue streams is definitely a must have, although you are not fully usage based

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact