There was a time when they charged for data points/performance traces ingested into the system. At our scale, we were paying around $100/month. We were prepared to scale that to their, I think it was, $550/month plan when our usage got that high.
They relatively recently changed their structure to charge per registered user. This would have raised our bill to around $1500/month at our current scale, to get all of of the stakeholders in there.
This is a cost incongruent with the value we were getting out of it. Even a ~$500/month price tag does not correlate with the value received, at our scale. It would one day (its a great product), but not today. So, today, we have two employees who have access to that, keeping our spend the same.
Here's the key component of this pricing change though: They will, no longer, be able to grow revenue with us. A pricing change forced us to make organizational changes. Those organizational changes mean that fewer people are seeing any value the product could deliver. When fewer people see the value, then the product has fewer advocates within the organization; its fungible utility will eventually be rolled into a competing product we already pay for, like Datadog, even if the experience is worse, because when we discuss Engine its always prefaced with "Oh, I think Dave in ops uses that, no one else does".
I have a similar story. Year is 2014 and client was using a very specific payment processor because the client was part of UK government and credit card processing was to be done using only that processor - you know, politics and stuff when dealing with government.
So the payment processor, after absorbing a good chunk of this organization became a behemoth, with a lot of political power and overnight they decided to charge additional license fees if you are throwing more then 5 connections/second from same IP to be processed.
Of course the client was upset and asked me if there is a solution before shelling what was possible more then a few million pounds (GBP, not the weight) per year in those fees. My solution? Made them just increase their pool of IP addresses from internet provider and additionally made an intermediate proxy which had the job to gather user requests and spread them to up of 4 requests/second to said processor. When waiting for your card to be processed usually the end user doesn't mind waiting extra 10 seconds, seconds that gave my proxy plenty of time to balance the requests. AFAIK it works without hiccups to this day. And of course, client only thanked me like government thanks to medics in COVID nowadays, all talk and no extra dime (apart from what we agreed upon). Oh well, I take pride in a job well done.
You're wrong. I have plenty of clients that seeing my efforts in putting that extra-mile for their project paid a bonus as well. But that's because I have good communication with them and plenty of times when they need it something fast I simply code it in front of their eyes instead of "let me see these requests and I get back to you". That's the difference between a senior developer and a junior one.
Then you're doing it wrong. You see, this needs to be done after you already coded the application at least on 2 different versions and the codebase of it it's over 50k lines and at least a year old. Then implementing something fast it blows their mind especially when they have the proverbial carrot in that proverbial place. As for overpaying is not the case since I am paid hourly. I prefer to blow their mind from time to time in order to do repeat business instead to always be "I'll get back to you" and have them feeling that I'm procrastinating.
I suppose it depends on business size, other than being appreciative, they might also want to keep the provider happy. They want the business to keep going without a hitch and finding replacements is not always a smooth process
Would the right move have been to see the value you could give to the client, and charge more at that point for an additional service to capture some of this value?
No. At best give a hint or make a joke comparing you to those lawyers that they seen in movies winning lower prices/fees for their clients. If they get the hint and / or act accordingly it boils down to what kind of person they are, but in no way make them uncomfortable by bringing this ever again. You may lose them instead and it's preferable to do repeat business instead.
People joke developers are a very special breed of deer easy to get scared and lose focus when working. Tell you from experience, clients of developers are the same, but in their case you lose their wallet / business they bring. Personally I prefer to have long-term relation to my clients.
This is an important point. A lot of companies do great revenue by selling seats, but that model is obviously not always applicable. In this case, you're pointing out that the marginal utility of a product like Apollo Engine is not driven by the number of users, but by the usage. In other products, say Box or Dropbox, the marginal utility is in how many people in an org you can get using the product, not in how much you use.
The license costs ~18.000€ per year.
Luckily it‘s a free floating license that can be reserved by the user.
So it can be fully utilised and a wider pool of users sees the benefit and the great value add of the product.
Per user licensing with that pricetag would not have gotten managerial consent
Your argument makes sense but not Dropbox pricing then. Their business pricing costs are per user. If they become more entrenched and valuable the more people use them, then extra users should be free, initially? (And maybe just charge for storage)
In general for SaaS, does it make sense to let customers choose between two (or more) pricing models, depending on their needs? Does this cause too much complication for the business? Curious why I haven't noticed schemes like this, other than at "enterprise" tiers where the customer is paying a lot for something closer to a custom solution and prices are negotiated.
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.
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).
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.
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.
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.
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.
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.
That would allow the thought the upper executives aren't infallible. An upper exec can never show vulnerability, especially to something like a business plan.
And that has ripple effects if they deal with vulture capitalists as well.
Their enterprise pricing is disgustingly grandiose. At our relatively small scale (just a few tens of millions of requests per month) they wanted five figures a month after the price change.
Nope. We'll just roll our own solution.
Whichever sales and marketing guy is responsible for that atrocious pricing will ultimately be responsible for the product failing. I don't know who's going to pay those absurd prices.
That is crazy when APM is such a saturated market. Granted, there aren't a ton of GraphQL-focused APM tools that are automatically aware of field resolution times and such, but GraphQL makes it a cinch to support; if a company like Datadog came in and added it to their already existing APM suite, Engine would be finished. Datadog APM is expensive, but it's generally interesting beyond GraphQL, and its not five figures expensive at this scale.
Datadog already has an Apollo integration. It's not as good as Apollo Engine but when it's 80% of the product for 1% of the price then it's a no-brainer. We already paid Datadog anyway.
The corollary to this is a lot of businesses don't care about $1500 a month, or $10k+ a month, or rather they see an appropriate amount of value, or they value not having to switch. It makes more sense for Apollo to focus on this business. And that is especially true if they have a product that is approaching a commodity.
How easy would it be to estimate costs based on something like data points/performance traces? On the one hand, it makes total economic sense to align pricing against utility but I’ve also heard for larger enterprises, something that lets them price things out for the future helps with cost management.
From an SE/SO professional, can I rant here for a moment?
Marketing and Product rag on Sales a lot for discounting. Nevermind the fact that we own the touchpoints with an account, so it only makes sense that we'd know what any individual account needs. I've had this issue with Marketing and Product professionals since I started in Sales, and even more-so when I took over Sales Enablement and Sales Ops.
For one, pricing is a big deal, but value is bigger. I could sell you on that $1500/user easily by giving you a work product that factors the product roadmap, your business roadmap, and makes a compelling ROI case for you. I'm willing to give you those 8-11 hours.
But we both know it'll be wasted. Because in 90 days, Marketing will push a discount campaign that conflicts with preexisting agreements, and thereby throws all of that work product up in the air. We'd have to go back to square one and recalculate everything to see if a deal even exists. Or Product decides to drop the roadmap, delay a feature, realign to attempt to capture more of a saturated market.
You know who sets pricing? Pricing experts. And maybe, just maybe, if they spent five minutes on a discovery call with you, they'd understand why you bring up discounts, why I would rather give you the discount, and why both of us walk away knowing we missed an opportunity for quality relationship-building.
I tried this once with an account. We locked their pricing down, pushed a work product out justifying our use case. The account came back and requested we drop the discount, that they saw the additional upfront cost (nearly $40k+) as an investment in our roadmap that could return utility for them sooner rather than later. We made it six months post-close before Marketing and Product decided to completely drop the current roadmap and work on something else. I had to issue more than $22k back to that account, and we got forced into RFP by the parent org, which we lost and subsequently lost all business from them, domestic and international.
So. Thank you for airing your perspective. And just know that people like me have stormed in and out of meetings, and still do, trying to stop this BS.
I've been on both sides so I understand your perspective.
Everyone wants to sell on _value_ and in an ideal world you could go up the food chain and say, "hey, if we spend $10,000 on this, we save $100,000 in employee hours". That should be the easiest decision in the world, especially if you could come back in a year and figure out it was really $105,000.
However budgeting in just about any organization I've been involved in doesn't work like that. You ask for $10,000 and there's no budget for it. Even if there is, there's no guarantee that next year you're not going to have to "tighten belts" and "sharpen pencils".
> "in an ideal world you could go up the food chain and say, "hey, if we spend $10,000 on this, we save $100,000 in employee hours". That should be the easiest decision in the world, especially if you could come back in a year and figure out it was really $105,000."
In an ideal world, yes. In the average large organization in the real world, though, very few people care about "saving employee hours". Particularly in middle management.
When a team's workload falls by 50%, there's rarely a magical stream of "useful work" that arises to replace it with. More likely, the team just sits around twiddling their thumbs; you either need to fire them, or concoct some busy work for them (defeating the point of the exercise in the first place).
Middle management are never going to gut their own team, because their headcount is what justifies their own position. This is also why your organization never has the budget for $10,000 - any money defaults to headcount, because headcount entrenches managerial authority.
Unless you're selling to C-suite (and can quantify the headcount reduction), "saving employee hours" is a terrible sales proposition for large enterprises.
> However budgeting in just about any organization I've been involved in doesn't work like that. You ask for $10,000 and there's no budget for it. Even if there is, there's no guarantee that next year you're not going to have to "tighten belts" and "sharpen pencils".
So.. a bigger question. Why doesn't budgeting work like this?
If the employees that you saved time from are hourly, you can just cut some hours and probably save money. Although you have to offset that with reduced morale if you cut employees/hours.
If you're saving time for salaried employees, you probably can't just cut hours. Now you have 1,000 spare man-hours this year, what do you do with them? If you saved 1000 employees the same amount of time per day, each of them has an extra 13.7 seconds per work day. A basically useless amount of time. If you freed up that time from only 100 employees, each gets an extra 20 minutes a day, which is an actually useful amount of time, almost 2 extra hours a week.
Assuming that you have saved a significant enough amount of time per employee, then the question becomes do you actually have productive work for them to do? You only saved money if you were going to hire people that you no longer have to hire, if those employees can create something with that spare time that generates revenue, or if you saved enough time that you can fire employee/s.
It's the same concept as discounts. Yes, discounts can save you money, but only if it was something you were going to buy anyways. It's like buying a new phone because it's 20% off. If your old phone was on it's last leg or you were going to buy one anyways, you saved 20%, yay. If you have a brand new flagship phone and you buy a new one just because it's 20% off, you haven't actually saved anything.
right. the money has to come from somewhere. you dont get an "employee hour rebate" from employee hours saved. maybe you should, but in reality it doesnt happen. anyway employee productivity claims necessarily get taken with a huge grain of salt. need to hit people over the head with the benefits.
Never sell your roadmap. $50k isn’t worth one of the few advantages startups have: agility. It’s also distracting. You get to have these fun hypothetical conversations instead of talking about the product you have. Sell what’s on the truck.
Was the product work discussed and planned with the product management and the developers? Did they understand what the client wanted? Did you follow up and liaise between product development and client during all this time?
To be fair one $22k customer is not much for a SaaS business with many or large customers. It does not justify spending months of work on a "feature" unless other customers also need it.
More importantly. Do you follow up on the feature and put product development in touch with the client to make it happen? It's always easy for sale to discuss whatever directly with the client and swear it's coming next, but what the client wants is super blurry (at best). Nobody can work on a task they do not understand, especially 3 months later when there is some (planned) time to work on it, so it's simply dropped. Thus is the cycle of how things are promised and cancelled.
It's enterprise sales so every contract is assumed to be above $10k.
One $22k contract may a lot for the bonus basket of the person closing the sale, but it is not be much for the company as a whole compared to the 20 other contracts being negotiated and the 200 current enterprise customers, and it definitely means nothing for the product/marketing groups who won't see a dime.
That being said I absolutely agree that if a customer is willing to pay for something, it's a very clear indicator of interest and it should be investigated. Hope it is easy enough to add and it is useful for every other customer!
There was a time when they charged for data points/performance traces ingested into the system. At our scale, we were paying around $100/month. We were prepared to scale that to their, I think it was, $550/month plan when our usage got that high.
They relatively recently changed their structure to charge per registered user. This would have raised our bill to around $1500/month at our current scale, to get all of of the stakeholders in there.
This is a cost incongruent with the value we were getting out of it. Even a ~$500/month price tag does not correlate with the value received, at our scale. It would one day (its a great product), but not today. So, today, we have two employees who have access to that, keeping our spend the same.
Here's the key component of this pricing change though: They will, no longer, be able to grow revenue with us. A pricing change forced us to make organizational changes. Those organizational changes mean that fewer people are seeing any value the product could deliver. When fewer people see the value, then the product has fewer advocates within the organization; its fungible utility will eventually be rolled into a competing product we already pay for, like Datadog, even if the experience is worse, because when we discuss Engine its always prefaced with "Oh, I think Dave in ops uses that, no one else does".