Our Shift to Usage-Based Pricing(appsmith.com) |
Our Shift to Usage-Based Pricing(appsmith.com) |
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!
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’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.
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'!
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.
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.
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.
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.
Your story about the vendor is so commonplace. Paying for software only when it’s used makes so much more sense.
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.
Open source + pay as you use + capped pricing solves a lot of it.
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.
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.
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.
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?
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.
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?
Anyone with this same issue, please upvote!
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) ?
I’m running Appsmith Cloud.
This is mostly a thing in consumer products though, perhaps for b2b it is different.
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.
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!
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
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.
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.
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.