I don't know about that. I suspect, generally speaking, per-user billing does not work for the vast majority of SaaS. It can really only work well in communication tools, where (1) most organizations receive a lot of value, (2) there's a network effect in play, and (3) expenses incurred by the provider generally correlate with the number of users. Slack. Jira. Notion. Etc.

For an APM tool like Apollo, only one of these requirements is true. It does provide a lot of value. But, there's no network effect, and their expenses do not correlate with users on the platform. That last point is the craziest one; being long-time users of Meteor and Apollo, I've always questioned the technical and executive leadership behind the Meteor Development Group (now Apollo), and they've done nothing in recent history to give faith that its a well-ran organization.

Retool (https://retool.com/) is another weird one. Amazing, amazing product. Truly transformative; what they're building there is unreal. There's a very light network effect in play, and usage may correlate better with users-in-app than it would with Apollo Engine, but charging per-user still feels weird. For them, I feel some form of bucket'ed plans, which allot X users, Y "applications", plus gated feature sets like SAML and Audit Logging, would make more sense. But, what do I know.

Per-user billing works when the value is obvious and the price is low.

If you have a B2B SaaS product your goal should be optimizing for getting the maximum users in an organization. The more people who use your product:

- The harder it is to move off your product

- If people like the product, when they leave, they'll evangelize your product to their next employer

- It's less likely that different teams/business units/etc will try a competitor's product because there's no seats available for them (and the money is going to come out of their budget anyway--they might as well decide on the product)

- You're not causing friction for team leads who have to justify budgets every year

How many people have worked somewhere where there's 50 seats paid for and you can't go to 51 because that takes you from "Pro" to "Enterprise" at a huge jump? There's way too much shenanigans that goes on because companies make paying them money painful.

I've been working on evaluations of several enterprise developer tools in the last month and without fail all have licensing requirements that are per-seat and painful. The result has been that instead of the whole organization embracing the tool, a much smaller set of users is going to get it. The thing that's crazy is that the cost to the SaaS provider has nothing to do with the number of users.

> The thing that's crazy is that the cost to the SaaS provider has nothing to do with the number of users.

Surely their support costs scale with the number of users? This might explain some anti-growth behaviors, support is expensive and a lot of companies struggle to get it right.

Support costs has no relation to number of users. It's constant time O(10) in engineering speech.

It doesn't increase going from 100 to 500 to 2000 users, because none of these users can raise support requests to the vendor. It's only the person (or micro team) who did the product evaluation and drafted the contract who has contact to the vendor support and sales team.

I'm not convinced. Even if only one person at the company has access to support, he's going to have more people asking him to submit tickets about their problems when there are 2,000 users vs 100.

This doesn't happen in practice because the 1900 more employees do not know who is that person and couldn't figure it out even if their life depended on it.

If you've worked in any large organization, above one thousand employees, doesn't matter how many above really. For any specific system, there are often only 1-3 people who are familiar with it and have access and would be willing to touch it.

There will be a few tens other employees who knows about them and have half a clue what they do (typically same department or neighbors sitting nearby). If one of those hear you looking for help on X, they can direct you "oh I think it's managed by that guy". The other 1900+ can't help you.

Having been the unlucky developer at work trying to track down whom to forward a ticket through (100k employees), for both internal services and external vendors. It's not uncommon that it takes weeks to find the one person. There are quite a few I've never found.

Very interesting insights

This might be true in enterprise SaaS (even then it's risky) but not in small/medium business. Particularly if you are using Intercom etc in your product - it's expected that you'll allow any user to contact you.

So yes, support can grow as user counts grow. But it shouldn't be a major expense (if it is that's a product failure).

In the financial systems/trading world high per-user pricing is considered normal.

Most "investment information"-type products are 25K-50K/user/year.

It's likely some people here will consider this low pricing, but it's a significantly different pricing model to the sell cheap, stack high $9 to $50/user/month type app.

That's only for products addressed to traders, a very limited audience. For example the bloomberg terminal that sits on their desk.

That pricing model is not applied to most information, like pricing data and any sort of API, because these are not about physical users. (They do charge a ton but not per user).

> That's only for products addressed to traders, a very limited audience. For example the bloomberg terminal that sits on their desk.

It's not, actually. There's a bunch of financial information products that aren't aimed at traders that are around this price point.

Pitchbook is a good example. $30k/year.

And the whole point is that it's a limited number of people. The price has to be high to make it worthwhile.

There's a bunch of markets like this where your pricing advice isn't correct and that needs to be noted.

The retool pricing is so annoying! Not only is the price per-user, but we found a weird SSO bug (well, I call it a bug) where if there is a company account and a new person logs in using google, they get added to the company account. Meaning your price can go up without you explicitly inviting users.

We have ended up telling everyone to use Retool with their personal email, then if they want to add an app they made to our company account (so they can used more advanced features eg. embed mode) they should chat to one of the small number of people with access to that account. It's mega annoying and I'm sure heaps of people don't bother.

I hope the team at retool reads hacker news.

Hi, I'm the founder of Retool. (I do indeed read a bit too much HN, hah.)

Thank you for the feedback — that does sound infuriating. We were optimizing for sharing of applications, but it sounds like the workflow you've adopted is really quite annoying. I'll have a think about what we could do here that might help (e.g. perhaps disabling "auto-adding" to accounts). If you have any suggestions please let me know (my email is in profile)! (I will send you an email by end of day otherwise with some thoughts...)

We view Retool as an option for building ultra lightweight apps when our normal app development flow (which is already very lightweight) is too heavy (read: costs too much in terms of developer time).

But Retool is too expensive for us, because we have many situations where we might use an app 100 times max for the life of the app, spread over a dozen or more users. Your pricing didn't work, even though your product did and I'm 100% certain you would be profitable with us as customers.

Hi, thanks for this message. I really appreciate it, since we generally don’t hear about “I didn’t buy because of the price” from the customers that already paid us, haha.

One thing we don’t advertise — we only bill for active users every month. So if 10 people login during a month, but 50 don’t, we only bill you for the 10. Do you think that’d help you guys?

(I’ll send you an email in the morning to get more feedback and see what kind of pricing would work for you. Thanks again for the feedback and for trying Retool!)

I'm a perfect Retool customer; didn't buy due to the pricing, and we spend $10K+/month on computing/service and many tens of thousands on developers, and about a dozen SaaS companies (the usual suspects and some others).

But we have a ton of part time, low hours customer support we would use with Retool and the pricing was just obscene for our use case. Would have loved to use it though!

Hi, thank you for the kind words! (I'm the founder of Retool.)

Per-user pricing is indeed tricky for us, since people oftentimes think about the value as per-app, not per-user. But ultimately, we want to encourage, not discourage the building of apps on Retool, and our best customers view Retool as a platform for building all their internal apps. (The best customers typically build 100+ apps on Retool.) That's why we don't price per-app.

But it's possible per-user pricing also isn't optimal. If you're open to it, I'd love to bounce some ideas off of you. Do you mind sending me an email? (I can't see the one in your profile.) Thanks!

It makes sense for the pricing to be aligned with what the users perceive as their usage/value. In any other shape, customers can and will adjust their usage or switch to something else.

When you start selling per-seat licenses, everyone is incentivized to reshape usage so that only one seat is needed. That one seat is used by a team member who becomes the internal expert on the service, while everyone else turns to him or her for help

And the product is cancelled once the employee leaves or transfers to another team.

Assuming the employee doesn't decide to abandon the product first, because who wants to be the only person on a tool that can't be used by any of your teammates or interns.

That, or everyone uses the same login tied to a shared user.

Sometimes it makes to have a super complicated pricing algorithm so (usually very technical) users can tweak exactly what they do and don't want. Remember the early Heroku pricing page?

99% of the time if your pricing page doesn't have a list of prices along the top, that will be a nonstarter for a non-technical business oriented person.

I think the current thinking is that you should keep your price down to 3 levels (but the same model) to keep it in one easy to read line on your landing page / price page so that potential customers will not be confused.

If you give them multiple models and ways to do things then they will have to think over what is right for them, and someone thinking over it might decide not to go with you.

On the one hand I can see the point, I hate to think too much over things. But I also hate how often products don't have a reasonable model for my use case.

I am quite curious why business plans themselves are not generally subject to a/b testing....

Well, it would be like splitting a company into two parts competing with each other. And wouldn't necessarily determine which plan is better - maybe plan A is better on its own but was undercut by competition from plan B?

> Well, it would be like splitting a company into two parts competing with each other.

Presumably you'd have to design the A/B test around this to get much use out of it. However, when you're just starting a service and not sure how consumers will view the value of it, the benefit is obvious.

Stores do a/b testing all the time, just by varying the products they carry.

Users talk to each other and hate it.

Plus complex A/B test (eg per user vs per app billing) are complex to build and hard to get statistically significant results. You might have a perfectly reasonable SAAS business with 100 customers.

Hotel and flight companies do that, it’s a terrible user experience.