5 ms·

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 communicat

by 013a 6y ago

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/ 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.

gav 6y ago
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.
- apatters 6y ago
  > 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.
  - user5994461 6y ago
    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.
    - apatters 6y ago
      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.
      - user5994461 6y ago
        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.
ghiculescu 6y ago
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.
- dvdhsu 6y ago
  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...)
  - erichocean 6y ago
    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.
    - dvdhsu 6y ago
      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!)
dvdhsu 6y ago
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!

by 013a 6y ago

gav 6y ago

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.

apatters 6y ago
> 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.
- user5994461 6y ago
  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.
  - apatters 6y ago
    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.
    - user5994461 6y ago
      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.

ghiculescu 6y ago

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.

dvdhsu 6y ago
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...)
- erichocean 6y ago
  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.
  - dvdhsu 6y ago
    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!)

dvdhsu 6y ago

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!