Our Shift to Usage-Based Pricing
appsmith.com
Our Shift to Usage-Based Pricing
1–10 of 41 posts
Re: Our Shift to Usage-Based Pricing
#2I’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?
Re: Our Shift to Usage-Based Pricing
#3Re: Our Shift to Usage-Based Pricing
#4I 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.
Re: Our Shift to Usage-Based Pricing
#5I 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.
Re: Our Shift to Usage-Based Pricing
#6I 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 aw…
Your story about the vendor is so commonplace. Paying for software only when it’s used makes so much more sense.
Re: Our Shift to Usage-Based Pricing
#7I'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.
Re: Our Shift to Usage-Based Pricing
#8I 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.
Re: Our Shift to Usage-Based Pricing
#9I 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.
Re: Our Shift to Usage-Based Pricing
#10I 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.
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.