9 ms·

I can call out one example of a poorly executed price raise: Apollo Engine (https://www.apollographql.com/pricing https://www.apollographql.com/pricing) There

by 013a 6y ago

I can call out one example of a poorly executed price raise: Apollo Engine (https://www.apollographql.com/pricing https://www.apollographql.com/pricing) 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".

tomjakubowski 6y ago
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.
- 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.
        6y ago
- TAForObvReasons 6y ago
  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
  - floydnoel 6y ago
    That, or everyone uses the same login tied to a shared user.
  - user5994461 6y ago
    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.
- monadic2 6y ago
  I am quite curious why business plans themselves are not generally subject to a/b testing....
  - crankylinuxuser 6y ago
    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.
  - praptak 6y ago
    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?
    - monadic2 6y ago
      > 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.
    - cultus 6y ago
      Stores do a/b testing all the time, just by varying the products they carry.
  - dgellow 6y ago
    Hotel and flight companies do that, it’s a terrible user experience.
  - nl 6y ago
    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.
- pc86 6y ago
  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.
- bryanrasmussen 6y ago
  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.
ooobit2 6y ago
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.
- gav 6y ago
  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".
danielrhodes 6y ago
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.
- xchaotic 6y ago
  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)
- oaw-bct-ar-bamf 6y ago
  Different product at my dayjob came to mind. 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
deleted 6y ago
[deleted]
0xy 6y ago
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.
- 013a 6y ago
  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.
  - 0xy 6y ago
    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.
- tmpz22 6y ago
  > disgustingly grandiose Just like GraphQL itself.
unnouinceput 6y ago
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.
- bobbylarrybobby 6y ago
  It's a rare client who pays more than the agreed-upon price.
  - unnouinceput 6y ago
    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.
    - eru 6y ago
      Well, bobbylarrybobby only said rare. Not 'non-existent'.
jiux 6y ago
Did you ever reach out to the Apollo team to express this concern?
tixocloud 6y ago
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.
gnopgnip 6y ago
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.

by 013a 6y ago

tomjakubowski 6y ago

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.

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.
      - 6y ago
TAForObvReasons 6y ago
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
- floydnoel 6y ago
  That, or everyone uses the same login tied to a shared user.
- user5994461 6y ago
  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.
monadic2 6y ago
I am quite curious why business plans themselves are not generally subject to a/b testing....
- crankylinuxuser 6y ago
  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.
- praptak 6y ago
  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?
  - monadic2 6y ago
    > 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.
  - cultus 6y ago
    Stores do a/b testing all the time, just by varying the products they carry.
- dgellow 6y ago
  Hotel and flight companies do that, it’s a terrible user experience.
- nl 6y ago
  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.
pc86 6y ago
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.
bryanrasmussen 6y ago
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.

ooobit2 6y ago

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.

gav 6y ago
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".

danielrhodes 6y ago

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.

xchaotic 6y ago
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)
oaw-bct-ar-bamf 6y ago
Different product at my dayjob came to mind. 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

deleted 6y ago

[deleted]

0xy 6y ago

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.

013a 6y ago
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.
- 0xy 6y ago
  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.
tmpz22 6y ago
> disgustingly grandiose Just like GraphQL itself.

unnouinceput 6y ago

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.

bobbylarrybobby 6y ago
It's a rare client who pays more than the agreed-upon price.
- unnouinceput 6y ago
  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.
  - eru 6y ago
    Well, bobbylarrybobby only said rare. Not 'non-existent'.

jiux 6y ago

Did you ever reach out to the Apollo team to express this concern?

tixocloud 6y ago

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.

gnopgnip 6y ago

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.