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

21–30 of 41 posts

Re: Our Shift to Usage-Based Pricing

#21

Post by IanCal »

OJFord wrote: post #20
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…

Rows isn't the amount of data, and it has no link to how complicated it is to create/verify/store. I'd rather pay by time & actual storage.

Want to load a billion tiny rows of super simple data into snowflake? Cheap. Create a table out of really tricky nested joins/complex comparisons? Expensive.

Re: Our Shift to Usage-Based Pricing

#22

Post by cryptonym »

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…

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

Not sure everyone is aligned. Sounds like Snowflake got no incentive on optimizing queries. They even got an incentive doing the opposite. They must keep their infrastructure as-is without any optimization on compute time nor storage to earn the same amount every month.

Re: Our Shift to Usage-Based Pricing

#23

Post by sverhagen »

I experimented with Appsmith (and Budibase, and to a lesser extent a few others) for about a week, and it was just a very painful experience. The simple examples are simple, but the curve goes up quickly, for example if you want to hook up a few APIs, instead of a database. As an experienced developer (but not normally in React), just building something off of a React starter app, with off the shelf components is just so much quicker than using tools in the Low or No Code category. I spent my next few days building the tool I wanted in React, and it was a breeze. Less experienced developers (not-developers) may not have that choice, but it doesn't mean that these tools are going to be any better for them than they were for me. I admire the attempt, and certainly the dedication that's being put into these Low or No Code projects, but I think they're still far off.

Re: Our Shift to Usage-Based Pricing

#24

Post by arey_abhishek »

sverhagen wrote: post #23

I experimented with Appsmith (and Budibase, and to a lesser extent a few others) for about a week, and it was just a very painful experience. The simple examples are simple, but the curve goes up quickly, for example if you want to hook up a few APIs, instead of a database. As an experienced developer (but not normally in React), just building something off of a React starter app, with off the shelf components is jus…

I appreciate your feedback and review. There's a lot of work to be done to improve Appsmith. It's still early days for this space.

Now, you mentioned that you found it painful to hook up APIs. Was it when connecting to multiple APIs or integrating the API response with UI components? Was it just using the online editor instead of a code editor? I'd love to learn more about the specific challenges you faced.

On the other hand, you mentioned that building something in React was a breeze for you. What aspects of React made it easier for you compared to using Low/No Code tools?

Re: Our Shift to Usage-Based Pricing

#25

Post by shardullavekar »

Spivak wrote: post #5
shardullavekar wrote: post #3

I worked at a large enterprise and similar SaaS tools were outright rejected because the per user/month pricing easily crossed $20. It became unviable to use such tools. We had a lot of to and fro with supply chain over this. This pricing shift addresses the concerns supply chain had back then.

Don’t you just negotiate a sweetheart deal? What company won’t take a fistful of ARR?

That could have happened if the supply chain moved fast. In our case, they took their sweet time and played cold. They were also not convinced for a lock-in/renewal at a price (although negotiated). From their experience, they almost had to renew a SaaS software once it was 2 years into the company.

Open source + pay as you use + capped pricing solves a lot of it.

Re: Our Shift to Usage-Based Pricing

#26

Post by sverhagen »

arey_abhishek wrote: post #24
sverhagen wrote: post #23

I experimented with Appsmith (and Budibase, and to a lesser extent a few others) for about a week, and it was just a very painful experience. The simple examples are simple, but the curve goes up quickly, for example if you want to hook up a few APIs, instead of a database. As an experienced developer (but not normally in React), just building something off of a React starter app, with off the shelf components is jus…

I appreciate your feedback and review. There's a lot of work to be done to improve Appsmith. It's still early days for this space. Now, you mentioned that you found it painful to hook up APIs. Was it when connecting to multiple APIs or integrating the API response with UI components? Was it just using the online editor instead of a code editor? I'd love to learn more about the specific challenges you faced. On the ot…

Well, SQL, and connecting it to a UI, lends itself to a declarative approach, and I guess that's just simpler to catch in a simple form builder etc. Heck, MS Access did it twenty years ago (and so did many others). But for other things one ends up trying to capture imperative code (which is just very flexible and expressive) in a simple editor. From what I remember from the experience, you end up adding pockets of complexity in different finicky controls, that then have to all with together, while the actual code equivalent would just be a few lines of code and done. I don't think I'm speaking to it very eloquently, but I was just shocked, at the time, how little progress was made, as an industry, relative to (I'm gonna say it again) MS Access. This was a year or so ago, I'm sure you're making progress!

Re: Our Shift to Usage-Based Pricing

#27

Post by sokoloff »

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

Earlier quoted context omitted.

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 pa…

What’s Slack’s incentive to charge strictly no more for any individual user? I can see them going to $x per activity, capped at $15/user/mo and $10 * (total number of users)/mo, but if they’re getting $8/user/mo now, there’s little incentive to make that $0.01-$8.

Re: Our Shift to Usage-Based Pricing

#28

Post by jimmySixDOF »

WJW wrote: post #18
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 consum…

I agree with this reasoning where it concerns someone who already recognizes that what they are using is a worthwhile tool for what they want to do on a regular basis. But for a looser test drive situation sometimes the flat sign up here with autorenewal and don't forget to cancel darkish patterns can be a blocker to entry. I look at it like a pre-paid vs post-paid mobile phone story where sometimes you just want less friction and hassle than a contract even if it's benefits are better. The thought experiment below is simple and who knows if User A would come back to the tool if faces with a problem to solve in month 3 but I think it supports a UBP approach.

User Journey A One (out of 100 landings) decides to take a 1-month $10 subscription, fiddles around a little but at the end of the month is not convinced of the value based on how much the tool was used. Cancels Subscription.

User Journey B One (out of 70 landings) decides to put down a $10 prepaid amount for a block of product usage. Month 1 has limited usage. Month 2 has limited usage. But in Month 3, they face a problem this product solves and find long term value along the way.

Re: Our Shift to Usage-Based Pricing

#29

Post by rishabhkaul1 »

sokoloff wrote: post #27
rishabhkaul1 wrote: post #16

Earlier quoted context omitted.

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 pa…

What’s Slack’s incentive to charge strictly no more for any individual user? I can see them going to $x per activity, capped at $15/user/mo and $10 * (total number of users)/mo, but if they’re getting $8/user/mo now, there’s little incentive to make that $0.01-$8.

Ok, slack & notion are bad examples because often the entire team is on it by default.

But imagine tools, where there is high aversion to adding more seats unless you're 100% sure. Like CRM & CMS systems, or like Support tools (Zendesk), or shared inbox tools (like Front) or project management tools (Asana) and so many others.

Re: Our Shift to Usage-Based Pricing

#30

Post by fphhotchips »

cryptonym wrote: post #22
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…

> 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. Not sure everyone is aligned. Sounds like Snowflake got no incentive on optimizing queries. They even got an incentive doing the opposite. They must keep their infrastructure as-is without any optimization on compute time nor storage to ear…

Snowflake employee here, not speaking on behalf of the company.

Short version is that you would think so, but it doesn't work that way for at least two reasons.

1. If we weren't investing in product optimization, but our competitors were, we'd quickly be outpaced.

2. When we invest in optimizing queries for our customers, the ROI on the Snowflake investment goes up. This results in actually getting even more money than if we just didn't bother, because CFOs that see great ROI on an investment absolutely do not hesitate to throw more funding at that investment. Making the denominator smaller is a really fast way to make the ROI higher.

So while the incentive seems to be perverse on first glance, very quickly it becomes clear that this isn't the case on further analysis.

Post reply on HN