Our Shift to Usage-Based Pricing | Hacker News Reader

Our Shift to Usage-Based Pricing

appsmith.com

91 pointsarey_abhishek38 comments

This approach is fascinating - and I would love to hear more about it later on...

Specifically, the selection of the value metric as time spent in-app (eg. per user hour). This is value metric/pricing strategy that seems like its available to many companies. And yet very pick it as far as I can tell...

"the amount you pay is proportional to the value you receive from the product"

...but is it proportional to the amount of time a user spends in the product? Timely example: I just switched from a legacy bank with a bad UI to one of these neo-banks, which has a slick UI. I spend way less time with the new bank - and its not because i am getting less value...

It seems like this could create a bunch of suboptimal incentives.

For instance, in my last company, as the we optimized our product, user session time went down - not up (and yes, retention/NPS/satisfaction went up). B2B Users want to do their job quickly - not spend all day in a product. Setting OKRs with this pricing metric would lead to some interesting conversations internally...On the other side of the coin, customers will be incentivized to push time-consuming workflows outside of the product.

If you are trying to differentiate from competitors with more favorable pricing for cost-conscious customers, seems like something like Slacks fair billing policy that auto-downgrades dormant users could be an alternative direction.

I am also very open I am utterly wrong... like I said, I am honestly curious to hear how this goes. Good luck!

> I just switched from a legacy bank with a bad UI to one of these neo-banks, which has a slick UI. I spend way less time with the new bank - and its not because i am getting less value...

Pricing doesn't necessarily need to incentivize all good behavior. As you're aware, having a product with a bad UI is an incentive for your users to switch to alternative services.

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.

> 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'!

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.

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

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.

Was a heavy Snowflake user at my last company - and this is what we saw.

Plenty of profiling tools to show why a query was taking a certain amount of time allowed us to optimise things, and also, the product seemed to get quicker over time.

Also love that, unlike BigQuery, you charge by compressed data size, not uncompressed data size.

The next day, it looks like BigQuery started charging by compressed data size. Any opinions on Adobe bringing back perpetual licenses? Or... do you have any stock tips?

I appreciate this pricing model.

I was on a saas vendor call just today (unrelated product category) and we were hit with a similar number to your example, in the $20k-$30k range, with a fixed component and then per use seat scales pricing. There was no discussion of activity based usage. I think if we could have a fixed base price, and activity usage pricing that's capped, even if the cap is higher, that would be awesome. Now for us, we're looking to buy in stop maintaining out own internal fork and all the downsides that come with it, just to make a meager sso shim.

I wish you all the luck possible here, and hopefully making the model work well for you and the team.

Thank you for the compliments! I’m hoping we succeed and inspire others to choose a similar model.

Your story about the vendor is so commonplace. Paying for software only when it’s used makes so much more sense.

Just wanted to add that usage-based pricing is a form of dynamic pricing, where the price for a given level of service is not fixed or is variable based on various factors like demand, supply, time of day, etc. In this case, the dynamic pricing parameter is based on usage.

When it comes to consumer protection laws, dynamic pricing is often treated as a form of price discrimination, where different customers are charged different prices for the same product or service. The legal treatment of price discrimination may vary from country to country, and it would be intriguing to see how usage-based pricing will be received in other countries.

Good point. I could imagine someone with an impairment might take longer to navigate the service and would thus be charged more.

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.

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.

It might actually be a good thing if you are close to your architectural scaling limits

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.

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.

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.

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.

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

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.

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?

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!

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.

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!

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.

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.

Hi HN readers,

I’m the CEO and co-founder of Appsmith. Appsmith is a 2020 open source project that aims to be a quick way to build apps that talk to multiple data sources. People use Appsmith when they need a CRUD app or an admin panel or a complex internal enterprise application. We are an open source alternative to Retool.

It’s hard enough to build a business model around an open source project and getting the pricing right is a critical step. So today, we’re announcing usage-based pricing for all Appsmith customers. Appsmith Business now costs $0.40 per hour per user, capped at $20 per user per month. The self-hosted community edition is still, of course, free and open source, and we still offer the Enterprise edition with custom pricing.

We strongly believe that user-based pricing, which most of the SaaS industry and most of our competitors use, is unfair to the customers, and that usage-based pricing is a much fairer alternative.

When it comes to coming up with the right price for using software, tech companies have traditionally leaned toward user-based pricing, where customers pay based on the number of people who have access to the software from their team or “workspace”. The truth is, user-based pricing tends to artificially limit the number of users who can experiment with the software, can lead to wasted resources, and therefore carries an awful lot of hidden risk for customers.

But we propose that there is an already-proven alternative! In fact, “adoption for usage based pricing has doubled over the past four years.” (https://openviewpartners.com/blog/state-of-usage-based-prici...)

We have seen a highly successful wave toward usage-based pricing in the tech industry from AWS to Snowflake that can and should also apply to internal app builder companies in order to create a better experience for developers and open the doors wider to continued innovation.

When we first started testing usage-based pricing eight months ago, internal app builder companies were still in the user-based phase (the overwhelming majority still are), including well-known names like our biggest competitor, Retool. As a result, Retool has no choice but to try to sign large enterprise contracts with the pricing locked up before the user sees any value. The prices range from $25,000 to upwards of $100,000. User-based pricing is an approximate way of measuring usage and value, but it’s simply not granular enough to accurately gauge the customer’s needs. They are paying for seats that never log in and Retool isn’t able to spend time promoting more usage and a better developer experience because they must move on to the next sale. We see this as a huge inefficiency in their pricing model that ultimately ends up being unfriendly to customers.

Software should exist to enable developers to create and innovate, not make them feel unfairly exploited. While we believe that usage-based pricing is definitely the right way to achieve that, we would love to hear from our community and beyond - what is the fairest pricing structure for software in your opinion?

> capped at $20 per user per month

the cost cap is brilliant. this is a hybrid between usage based and seat based pricing that addresses all concerns. well done and i'd love to read a retro after 6-12 months on surprises and validation

I would love to use Appsmith and pay-by-usage, but I’m blocked by not being able to SSH tunnel into MySQL.

Anyone with this same issue, please upvote!

https://github.com/appsmithorg/appsmith/issues/518

Hey zackkatz, I'm Arpit, the CTO of Appsmith. Thank you so much for surfacing this Github issue. I know it's quite an old one and we still haven't provided a fix. I'll bump this up internally on our priority list.

Btw, since you are trying to connect to your web host, can I ask if you are self-hosting Appsmith or you are using Appsmith Cloud (https://app.appsmith.com) ?

Hi Arpit! That’s wonderful news, thank you!

I’m running Appsmith Cloud.

Reply on news.ycombinator.com