Ask HN: SaaS Subscription or Usage-Based Pricing?

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

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”)

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)

You can also charge for minimum usage

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

Do both

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