Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Our Shift to Usage-Based Pricing

appsmith.com

Post reply on HN
Print view View original

11–20 of 41 posts

Re: Our Shift to Usage-Based Pricing

#11

Post by scottfr »

We've explored usage based pricing for our app which has a core unit-of-work that delivers value to the user. We've talked with various customers about adopting usage based pricing in place of our standard cost per user pricing model. We thought it would be great to align user costs with value delivered.

Turns out no one wanted the usage based pricing even if it could save them money based on their predicted usage. Companies preferred the consistency, clarity and control of a user based pricing.

We didn't try out a cost cap like the $20 here, so maybe that was a missing ingredient in our tests.

Re: Our Shift to Usage-Based Pricing

#12

Post by illwrks »

rishabhkaul1 wrote: post #10
benkan wrote: post #7

I believe that usage-based pricing is valuable to the customer, but I see one problem for the vendor: If each use of the product is billed, this provides an incentive NOT to use the product. In other words, you actively drive usage down. I'm not saying that I am against usage-based pricing or that it does not make sense, but especially in B2C markets, this might be a problem.

I didn't quite understand this. Why would the vendor have a problem with this - you mean rising cloud costs? For the customer the value is ofcourse apparent. They aren't locked into a monthly fixed price. Plus the cap helps drive predictability incase of spikes of usage.

I understand it to mean, if you're the type of customer that is a high volume user your costs go up, therefore your then incentivised to reduce your usage.

Re: Our Shift to Usage-Based Pricing

#13

Post by tokamak-teapot »

rishabhkaul1 wrote: post #10
benkan wrote: post #7

I believe that usage-based pricing is valuable to the customer, but I see one problem for the vendor: If each use of the product is billed, this provides an incentive NOT to use the product. In other words, you actively drive usage down. I'm not saying that I am against usage-based pricing or that it does not make sense, but especially in B2C markets, this might be a problem.

I didn't quite understand this. Why would the vendor have a problem with this - you mean rising cloud costs? For the customer the value is ofcourse apparent. They aren't locked into a monthly fixed price. Plus the cap helps drive predictability incase of spikes of usage.

The problem for the vendor is that their customers are encouraged to avoid using their product.

Re: Our Shift to Usage-Based Pricing

#14

Post by benkan »

rishabhkaul1 wrote: post #10
benkan wrote: post #7

I believe that usage-based pricing is valuable to the customer, but I see one problem for the vendor: If each use of the product is billed, this provides an incentive NOT to use the product. In other words, you actively drive usage down. I'm not saying that I am against usage-based pricing or that it does not make sense, but especially in B2C markets, this might be a problem.

I didn't quite understand this. Why would the vendor have a problem with this - you mean rising cloud costs? For the customer the value is ofcourse apparent. They aren't locked into a monthly fixed price. Plus the cap helps drive predictability incase of spikes of usage.

The vendor would have a problem with disincentivized usage becaused in the model, it earns the money purely by usage. It is a commercial problem, not a technical one. The company wishes to earn money, yet puts in place a model that decreases its only revenue driver.

Re: Our Shift to Usage-Based Pricing

#15

Post by rishabhkaul1 »

scottfr wrote: post #11

We've explored usage based pricing for our app which has a core unit-of-work that delivers value to the user. We've talked with various customers about adopting usage based pricing in place of our standard cost per user pricing model. We thought it would be great to align user costs with value delivered. Turns out no one wanted the usage based pricing even if it could save them money based on their predicted usage. C…

Hey Scott, Rishabh from Appsmith.

Absolutely agree with you. I do think it also depends on the kinds of companies you are seeing. In our case, we realized we have 1 member devs, but also 1000 member teams. And didn't want to drive all the larger teams towards a "contact us" button unless they were really large. So a standard user based pricing (which most of the players in our space have) didn't work for us. That's what led to the cap.

I agree communicating this is a challenge. We're spending multiple iterations on trying to have a good calculator (we're on your 10th iteration now ha!) on our pricing page to try to explain this. Coz once obviously it makes more sense from a budget perspective, but it's not necessarily intuitive. So end up getting questions around how we calculate usage etc etc. So trying to also beef up the FAQ section more.

btw, congrats on Text Blaze!

Re: Our Shift to Usage-Based Pricing

#16

Post by rishabhkaul1 »

tokamak-teapot wrote: post #13
rishabhkaul1 wrote: post #10

Earlier quoted context omitted.

I didn't quite understand this. Why would the vendor have a problem with this - you mean rising cloud costs? For the customer the value is ofcourse apparent. They aren't locked into a monthly fixed price. Plus the cap helps drive predictability incase of spikes of usage.

The problem for the vendor is that their customers are encouraged to avoid using their product.

That's interesting. Because that's exactly the behavior we're trying to prevent.

Think of the alternative: - A user uses the product for one hour and they pay the same amount as they would if you use it for the entire month.

I think that's where the cap becomes important. Think of the cap as a traditional user based pricing. Now only in the case where EVERY single user ends up using it VERY actively will they ever pay that amount.

In every other case, they end up paying less, because they're only paying for the value.

So if Slack is today charging $8/user, but instead they change their model to max $8/user, but users who message lesser pay lesser than $8, then it's a fantastic decision commercially. Esp as an org scales.

I think the real issue is that, when you add a new user, you're not really sure if they're going to use the software fully, so you're hesitant adding them (think about buying a salesforce license for a solution engineer). But if someone said "hey, you don't pay the full amount, till they end up using very actively", then you're more likely to invite more people because the risk of racking up costs is lower.

So the hope is also that a pricing like this leads to more experimentation and wider adoption by a customer.

Re: Our Shift to Usage-Based Pricing

#17

Post by benjaminwootton »

I think they key with usage based pricing is to have the right units.

I’m in the data space and a company like Snowflake has a model where you pay for compute by the second and storage by the byte. Very simple, transparent and everyone is aligned.

Some other database companies try this though and it feels very opaque. When you get into an enterprise sales cycle and pricing negotiation, they try to build a price based on data ingested with big steps up at each tier. I really hate the opaqueness of that model combined with bespoke pricing.

Some of the ETL companies have tried to charge by number of rows loaded. That just feels too arbitrary to me, more disconnected from value incurred and quite risky.

I see a lot of this from the buyers side and I think the wrong consumption based pricing models holds back a lot of these companies. I know of $millions which would have been transacted on a more flat fee basis even if the net cost was likely higher.

Re: Our Shift to Usage-Based Pricing

#18

Post by WJW »

scottfr wrote: post #11

We've explored usage based pricing for our app which has a core unit-of-work that delivers value to the user. We've talked with various customers about adopting usage based pricing in place of our standard cost per user pricing model. We thought it would be great to align user costs with value delivered. Turns out no one wanted the usage based pricing even if it could save them money based on their predicted usage. C…

This is something that has been known for many years in the consumer space: customers dislike usage based price even if it would be cheaper. This is both because they don't like the unpredictability and also because now every transaction involves a tiny pang of losing money. "Unlimited for a constant fee" is much nicer psychologically, because you take away the guilt of using the app.

This is mostly a thing in consumer products though, perhaps for b2b it is different.

Re: Our Shift to Usage-Based Pricing

#19

Post by martin_a »

benkan wrote: post #7

I believe that usage-based pricing is valuable to the customer, but I see one problem for the vendor: If each use of the product is billed, this provides an incentive NOT to use the product. In other words, you actively drive usage down. I'm not saying that I am against usage-based pricing or that it does not make sense, but especially in B2C markets, this might be a problem.

> If each use of the product is billed, this provides an incentive NOT to use the product

We are running a special solution since 2020 with a "pay per order" model. I thought like that in the beginning, too. That has changed.

The product is just _so_ useful to us that we save so much money on each order that the processing fee is peanuts, compared to that.

So I think this might come down to the usefulness of the product. In our case with this specific solution it works very well, but I'm not sure it would for something like a database or something like that.

Re: Our Shift to Usage-Based Pricing

#20

Post by OJFord »

benjaminwootton wrote: post #17

I think they key with usage based pricing is to have the right units. I’m in the data space and a company like Snowflake has a model where you pay for compute by the second and storage by the byte. Very simple, transparent and everyone is aligned. Some other database companies try this though and it feels very opaque. When you get into an enterprise sales cycle and pricing negotiation, they try to build a price based…

> pay for compute by the second and storage by the byte. Very simple, transparent [...] Some of the ETL companies have tried to charge by number of rows loaded. That just feels too arbitrary to me, more disconnected from value incurred and quite risky.

Did you typo that the wrong way around? #rows seems way more connected to 'value incurred' for ETL than compute time to me. 'We help you load data, you pay by how much data you load' vs. 'we help you load data, you pay by how long it takes us'!

Post reply on HN