Our Shift to Usage-Based Pricing

This approach is fascinating - and I would love to hear more about it later on...<p>Specifically, the selection of the value metric as time spent in-app (eg. per user hour). This is value metric&#x2F;pricing strategy that seems like its available to many companies. And yet very pick it as far as I can tell...<p>&quot;the amount you pay is proportional to the value you receive from the product&quot;<p>...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...<p>It seems like this could create a bunch of suboptimal incentives.<p>For instance, in my last company, as the we optimized our product, user session time went down - not up (and yes, retention&#x2F;NPS&#x2F;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.<p>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.<p>I am also very open I am utterly wrong... like I said, I am honestly curious to hear how this goes. Good luck!

I think they key with usage based pricing is to have the right units.<p>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.<p>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.<p>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.<p>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.

I appreciate this pricing model.<p>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&#x27;s capped, even if the cap is higher, that would be awesome. Now for us, we&#x27;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.<p>I wish you all the luck possible here, and hopefully making the model work well for you and the team.

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

I worked at a large enterprise and similar SaaS tools were outright rejected because the per user&#x2F;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.

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.<p>I&#x27;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 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&#x27;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&#x27;s being put into these Low or No Code projects, but I think they&#x27;re still far off.

We&#x27;ve explored usage based pricing for our app which has a core unit-of-work that delivers value to the user. We&#x27;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.<p>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.<p>We didn&#x27;t try out a cost cap like the $20 here, so maybe that was a missing ingredient in our tests.

Hi HN readers,<p>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.<p>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.<p>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.<p>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.<p>But we propose that there is an already-proven alternative! In fact, “adoption for usage based pricing has doubled over the past four years.” (<a href="https:&#x2F;&#x2F;openviewpartners.com&#x2F;blog&#x2F;state-of-usage-based-pricing&#x2F;#.YYSQr9nMLvU" rel="nofollow">https:&#x2F;&#x2F;openviewpartners.com&#x2F;blog&#x2F;state-of-usage-based-prici...</a>)<p>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.<p>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.<p>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?

I would love to use Appsmith and pay-by-usage, but I’m blocked by not being able to SSH tunnel into MySQL.<p>Anyone with this same issue, please upvote!<p><a href="https:&#x2F;&#x2F;github.com&#x2F;appsmithorg&#x2F;appsmith&#x2F;issues&#x2F;518">https:&#x2F;&#x2F;github.com&#x2F;appsmithorg&#x2F;appsmith&#x2F;issues&#x2F;518</a>