Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: SaaS Subscription or Usage-Based Pricing?
119 points by JanSchu 6 months ago | hide | past | favorite | 52 comments
I'm in the process of building a SaaS product that enables marketers to combine data analytics with generative AI. I'm currently debating whether to implement a subscription model or a usage-based pricing model for this tool.

Does anyone have experience with how conversion rates are affected by these different pricing schemes? What are the pros and cons you've encountered with each approach?




My experience as a bootstrapped saas founder:

-at the early stages, usage models didn’t work for us because it attracted customers who were uncommitted to using the product

-the advantage of a subscription is that it filters out people who just want to use something occasionally (which is fine once you’re huge, but at the beginning you want people who are committed)

-I found it impossible to make enough money on the usage model. It’s maybe great for users but if you go out of business your users won’t be able to use it anyway

-we do automated real estate reports. When we charged per report people ran a lot less reports and tended to be stingy about running them. We wanted to encourage users to use it so an unlimited subscription made users happier, even if it meant their per report cost was higher. Also, we got tired of people computing the cost of a report mentally. Since the margins per report are good, an unlimited subscription works much better.

-once you reach a certain size having free and lower usage tiers can be a good thing but first you need a bedrock of recurring revenue that you can count on. Unless you have boatloads of VC money to burn.

-this will vary greatly depending on the specifics of your product. For example, developer tools that are easy to test out, but require a credit card to go to production make a lot of sense, but that was not us.

-if you can sign up very large customers that you know will use it a lot, usage models can make sense. But this requires a really really good product that already has PMF and requires that you can sell to mid market or enterprise customers and the sales cycles can be long. You can easily go out of business waiting to sign those customers.


> the advantage of a subscription is that it filters out people who just want to use something occasionally

One way around this is to require a subscription but the user gets the amount paid for the subscription as "free" usage and then they pay the normal rate for usage above that amount.


It sounds like you didn't limit the number of report runs in your subscription model, is that correct?


Usage-based pricing works great for core infrastructure type-stuff (think AWS, sendgrid, twilio), where the growth of your customers business inevitably means their spend with your business will also grow. Great incentive alignment for both parties.

Subscription pricing works best for end-user tools that help a certain function do their job better (ongoing). Why? If your target customer has to ask their boss for more budget every time they want to use your product — your business is dead in the water.


As a corollary, one-time fees work well for utilities that accomplish a goal where there is unlikely to be an on-going customer relationship.

Also, depending on the product or service, having a separate subscription or pay scale for individuals and businesses helps prevent sticker-shock for individuals and dismissal by corporations put-off by prices when they are too low.


Agreed. But also beware of customers who want to pay one-time fees for ongoing-need products, or to rephrase it; Ignore all pricing feedback you get from Hackernews.

On HN you're mostly talking to a niche of people who are both a) consumers and b) spend all day in code, not end-user tools.

Consumers, as a rule of thumb, mostly consume, and irrationally value their time at $0. They don't build things like companies do, so don't perceive any monetary value in doing something more efficiently via software like a company would. They'll waste hours of their life to save $5, because what would they be doing otherwise? Scrolling Instagram or watching YouTube, so who cares.

Coders, as a rule of thumb, mostly code, and irrationally value the code of other people at $0. In the back of their mind they always believe they can "code up a better replacement in a weekend." Even though this is 99.99% of the time not true.

So the intersection of these two groups could be the worst software market on earth.


Every seller has to think critically themselves about how to structure pricing in a way that accounts for user benefit, market alignment, and OpEx.

I recommend going through the BMG book process to be sure all of the big areas are considered. [0]

> Coders, as a rule of thumb, mostly code, and irrationally value the code of other people at $0. In the back of their mind they always believe they can "code up a better replacement in a weekend." Even though this is 99.99% of the time not true.

This comes across as reductive stereotyping lacking in nuance and denying individual abilities of real humans who may also happen to have other hustle skills like sales, advertising, and marketing. Please don't do this.

0. https://www.strategyzer.com/library/business-model-generatio...


I think it’s worth calling out how easy and common it is for software engineers to casually dismiss software they didn’t write themselves. If I had a nickel for every time I’ve seen someone casually hand wave away a mountain of complexity I would be a rich man.


100% true


> Great incentive alignment for both parties.

It can create unfortunate incentives though. For example, logging and metrics services that use usage pricing create an incentive to send less logs and metrics, which leads to reduced observability. OTOH, those are services where the cost for the provider scales somewhat linearly with the usage of the customer.


Having different tiers for the subscription service works well. That way high usage users aren't sucking up all the resources without paying for them.


> Great incentive alignment for both parties.

In many industries, the customer will feel punished for using the product - the opposite of what I'd want, as someone proud of the value their product provides.

Therefore disagree, depending on the existing mentality in the niche.


Pricing is going to depend on the product. For my SaaS I ended up going with usage-based pricing and am quite happy with it.

1. It aligns to my costs, so I'm not too worried about abuse.

2. It allows servicing "small" users, there is no need to jump onto a recurring plan. You can just buy one package of "credits" and use it for years (or even just coast quite a while on the free trial).

However I think there are downsides with the usage based pricing as well:

1. It discourages using the service. If each use costs money it is a small hurdle to clear. Even if it is cheaper most users will "feel better" with unlimited or pre-paid packages as they are using what they paid for.

2. Predictable cost to the user.

3. Can often be more profitable, especially for small users.


I think an important point to consider is whether your product is an intermediate good or a final good. Intermediate goods used as inputs for other software products are a good bet for usage based pricing because it’s easier for your customers to integrate that into their own cost and pricing calculations. Whereas a final good where your customer is the end user, it might make more sense to bill a flat rate subscription so you can charge based on the end user’s perceived value of the product. Tiered subscriptions with usage caps are a good hybrid model since you can ensure your cost of service doesn’t outpace your revenue


As a user I think I'd like a model that works like some transit systems I've read about. Those transit systems sell per ride tickets for say $2, day passes good for unlimited rides for one day for say $10, and monthly passes good for unlimited rides that month for say $50.

If you use their smart cards to pay for your tickets then they cap your daily spending at $10 (the price of a day pass) and your monthly spending at $50 (the price of a monthly pass). In effect they notice if you would have been better off if you'd have bought a day pass at the start of that day or a monthly pass at the start of the month and retroactively convert you to that.


Very complicated model for early business; not enough sample data to build the model and experiment is much harder than other methods (ie: monthly|usage)


Usage-based pricing models require you to prove/measure the real usage, which may be really hard and possibly extra work.

However, I personally prefer approaches, where not every request gets charged but instead having "packages" with a discount on every step, e.g.:

  - 2000 Requests -> 2$
  - 10000 Requests -> 8$
  - 100000 Requests -> 15$
  - unlimited Requests -> 69$
This way I also have a max. amount that won't ruin me, even if something goes wrong.


You can mix the two models as well. For example, have subscription plans that include a base usage level and have per use price if they go over their plan (some mobile plans work like that)


Could also consider usage-based for very low-volume users.


I went through this. Subscriptions are easier to start with, manage and understand and easier to sell. Once you've reached a certain stage and need to optimize for profit you will be in a better position to introduce. Monitor what your subscribers use/cost you.


One key question is the extent to which your own costs depend on usage. Some companies have to stick with usage-based pricing because otherwise they'd go under (unless they're well-funded). The downside of this approach, as others have noted, is that this tends to depress usage and generally makes a product less sticky because people are hesitant to embed it in their workflow.

If your costs don't vary a ton with usage, it could be better to offer subscription pricing. If need be you can offer tiers that support different levels of usage. You can also feature-gate other aspects of your product, so it doesn't seem like you're pricing based on usage per se. Rather, you'd be charging more for customers that need SSO, more than X seats, SLAs, etc.

I will say that one downside to having minimal marginal costs is that some customers will bristle at paying value-based prices. They'll think that if your cost is minimal then they shouldn't be paying much for your service.

It's really interesting to read all the different perspectives shared below. We each have our unique portal onto the pricing landscape, and seeing what others have learned, and how they put their perspective into words, is quite enlightening.


a good blogpost from a16z : https://a16z.com/usage-based-pricing-rule-of-thumb/


This was surprisingly insightful, thank you!


It’s not at all about your product, it’s about your customer, and you’re going to likely need both schemes.

Usage based pricing works well for customers who value flexibility more than predictability, and subscription pricing works well for those that prefer predictability (and probably want a discount). It makes sense. Customers in the first camp are growth oriented or otherwise undergoing a transformation of some kind. The latter group has stable operation and is looking to optimize.

Usage based pricing should be more expensive than subscription pricing to make up for the lower value multiple it gets should you raise or exit.


Subscription implies that your costs are roughly the same across different usage patterns by different users (otherwise you collect expensive users who under-pay for the resources they consume). Or, that you can tier your subscriptions in a way that makes sense for the bulk of your users.

Usage-based comes with more work in the short-term: more internal metering, controls for bill-shock, observability so users can see usage by billing vector, pricing/marketing work to help users understand their expected costs for different workloads.


As a bootstrapped startup, we are providing SaaS products for larger business customers.

We use a subscription model, which price depends on a very fixed metric of the customer. Think number of rooms in a hotel, it usually never changes.

Not based on users, as that might constantly change and we don’t want customers to think about, if the new employee gets an account or not or has to share it with a co-worker.

Subscription based revenues are more predictable, the user knows the price in advance, the user can easily clear the fixed budget with superiors, the accounting department knows what to expect every month, no one gets a bill shock, no one needs to worry about usage and budget.

We have like no variable cost, so we don’t worry about high usage.

It of course depends on the product and your target group, this works very well for us and our customers.


At https://scrapingfish.com/ we have both options, usage based https://scrapingfish.com/buy and subscriptions (monthly unlimited requests plan) https://scrapingfish.com/unlimited. Despite subscriptions being cheaper option per request, usage based is way more popular. Only less than 10% of our users have subscribed to unlimited monthly plan. I guess usage based plans give users more control over how much they spend or maybe they simply don't want to subscribe to another service.


Residential IP bandwidth is a commodity priced per GB. The rest is available OS for free. This isn't a SaaS exactly.


A lot of people have tons of subscriptions already, I would go with usage based pricing. It's a deal breaker for me, if I need to add a monthly subscription for something I don't use a lot.

But the most important thing is to get the product right.


Do you think this advice applies equally to a B2B tool like the one described? I feel like subscription overload is a B2C thing, but not so much B2B (where subscriptions to many physical and digital goods are expected).


It depends on the size of the business.

For startups, subscriptions can stack up fast and it's the same as B2C, they can't afford it. Subscriptions are liabilities.

But for medium sized businesses or larger, it depends on how much value the tool provides but should be fine, especially if they can fire somebody now that a fancy AI does his job. Enterprise pricing is a thing for a reason.


For me (as someone who hates subscriptions personally), the difference is that subscriptions I buy for my business help me generate recurring revenue. In my personal life, subscriptions perhaps make my life easier, but do not have the same leverage to create continuing benefit.

So I'm much more willing to buy subscriptions to help me generate not only more revenue but essentially a decaying annuity (due to churn) than I am to buy subscriptions for some personal benefit that disappears the moment I stop paying.


With AI, usage-based is becoming the norm because of how expensive and unreliable are any of the APIs that are (almost) capable of doing the work. If you need to run a prompt multiple times until it gets it right it can get very expensive.


What size of company are you targeting as your customers? Are you focusing on self-serve and marketing or deals and a sales team?

Do you already have customer prospects you could ask? Are they more concerned with a runaway bill or paying for subscription services they end up not utilizing?

Could you find a sweetspot in the middle? (“You only pay $3.14 for the days when an employee use the service” or “You pay for the usage, but it’s very transparent and predictable pricing, we’re not AWS”)


At the start, SaaS is a pricing and feature experimentation platform.

Baking in flexibility on delivering features packaged and priced differently becomes an unfair advantage.

Aligning pricing plans with feature flags can also help.

This might sound like additional work to the startup.

I would ask if you see your SaaS as a billing platform around features, or features that can't bill.

Billing will always evolve around clients in different industries, verticals, etc.

I have a targeted approach I have used many times before, happy to chat offline.


It depends on your product, and what you expect your customer to do with the results.

  * What does the product actually do?
  * What do they get for a "use"?
  * If the usage-based pricing is an add-on, what value does the product provide without it?
I suspect you're better off with subscription-based pricing in an emerging product category of AI-native solutions. But it really depends on the product.


Cool! All the best with the build and launch.

FWIW, I think that the conversion would be fine either way. If you haven’t already, it might be worth adding a free tier.

The data from the free tier then could answer the questions around what is a more effective model for your app. You’ll want to see healthy margins and you’ll want to mitigate for abuse that you actually see in the data from the free tier.


For early versions I’ve had a much easier time building with subscription model (used a third party, set up in one day). Unless it was a key differentiator for a customer choosing me, usage based was more complicated to set up for shipping quickly early on. There are 3rd parties that help with this but it’s more complex.


B2C or B2B? As a buyer of SaaS software for enterprise I have to fill in a bunch of risk assessments and procurement forms to get SaaS products onboarded. As such I normally find it much easier to get it signed off if there is an upfront budget expectation - so subscription pricing. Just a small point.


All of these responses are ignoring the cost of AI: I went subscription based for an app and power users almost took my shirt despite charging 3x-5x what comparable non-AI sites charge

I landed on a hybrid base subscription with guaranteed usage and usage based pricing past that


I almost always try to avoid subscriptions. I am happy to pay once if it solves my problem but less willing to pay for a long time regardless if I use a service or not, or how much I use a service.


Usage = can grow revenue faster with greater upside potential … but at the risk of no predictable revenue.

SaaS = more secure reoccurring revenue. Slow revenue growth. But highly predictable.


Another model I’ve seen is a combination of subscription and usage where there’s a monthly base and then additional charge for usage overages. Example is Sendgrid.


SaaS Subscriptions have gotten out of control. I do not need to pay you X per month to use software that I was able to purchase ONE TIME.


Ask your target customers specifically!

You can have the best of both worlds with tiered pricing. $20/month for x usage, plus $y for overages.


I’d start with a subscription for beta and see how you do with it.

Imo subscriptions are an easier sell, since it’s more predictable.


Subscription model works when the user is constantly in the app and using it or it has api's the user uses. Because then they feel like they're getting their money's worth from the product. If the user will only be using it monthly or quarterly. Then a usage based model is better. With usage model you may want to have a flat fee for storage. So that at least you get paid for holding the data until they come back to use it.


Do both

Subscription with a free tier, and usage based pricing above a certain amount.


We offered "usage+minimal base fee" (cost-plus) based first, then used that data to determine fixed rate plans based on the initial customer usage. We still offer both, but fixed rate outsells by far because of the reliable bill.. though it is generally more expensive for the consumer (as we take on the risk).

We find our customers (mostly education sector) flat out could not get variable pricing approved. There's probably many other teams and sectors in that boat.

That said, flat rate pricing is sooooo much easier to deal with... Especially if you want to pass through the cloud costs, and not use your own "usage determination"


You can also charge for minimum usage


The pro and con are the same. The pro is when you charge enough for healthy profit and good nights of sleep. The con is when you don't.

So in the beginning it doesn't matter. Maybe later it will, The only way to know is to pick one and see what happens.

Success and failure will be determined by the quality of your customers and the scale of your knucklehead mistakes. Your sales contract is rounding error. At Good luck.


It massively depends on the nature of the service and your target market.

A general piece of advice: identify the closest measurable factor(s) to "the more I do $X, the more business value I get out of the service."

For example, if analyzing more data improves business outcomes, consider usage-based pricing (e.g., GBs of data). If the value comes from sharing with other departments or collaborating, then these features could be part of a pro plan, or you might use per-user pricing.

Another important point is that it's usually better to have a customer pay nothing (e.g., a free tier or a 50/50 chance of converting them to a serious plan) than to have a customer who pays inconsistently, such as $0.75 one month, nothing the next month, and $1.10 the following month. These customers are problematic; they'll demand support and play the "I'm paying" card, and you'll incur card processing fees. Avoid this by setting a minimum charge or offering a small free tier to attract users who might pay later.

This is what I often end up at honestly, but it may not suit you;

Lets say each $thing is 1 cent.

Free trial Requires card, 14 days with 1000 credits (encourage urgency to evaluate now, not later - many eventually forget), customer pays with card for anything over the 1000 in those first 14 days - but is not auto charged for a standard plan on trial end. They are then emailed to encourage conversion or the account will be deleted 30 days from trial end (encourage urgency, keep a clean platform/GDPR compliance).

Standard $20/User/Month - each user gets 2000 non rolling over credits per month, but that is aggregated at the org level e.g an org with 5 users gets 10,000 credits. Additional credits are 1c.

Pro Additional features. Depending on how much value those create you either tack on a $featuretax e.g add $10 a user, or if they are just low value nice to haves/quality of life when dealing with large volume, then trade them for a higher minimum volume so $50/user/month gets you 5000 credits per user.

Anyone who does serious volume come talk direct, but they get a discount in exchange for contractually committed usage.

-Always possible to alert on overages at an account level (100% alert to main contact should be default), cap is usually appropriate too.

This model gets you a load of stuff for free, mid volume users can add extra users for free, or choose extra nice to have features instead or aswell. A minimum charge is instituted per user, regardless of thier usage. User is not feeling like each click costs money "It's included", at least until they're using your platform in volume at which point "they're in". Door is open to doing enterprise/high volume deals.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: