[HN Gopher] Ask HN: SaaS Subscription or Usage-Based Pricing?
___________________________________________________________________
Ask HN: SaaS Subscription or Usage-Based Pricing?
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?
Author : JanSchu
Score : 53 points
Date : 2024-05-16 10:35 UTC (2 days ago)
| dartos wrote:
| 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.
| rbetts wrote:
| 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.
| sakjur wrote:
| 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")
| nico wrote:
| 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)
| alok-g wrote:
| Could also consider usage-based for very low-volume users.
| brigadier132 wrote:
| You can also charge for minimum usage
| curious_cat_163 wrote:
| 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.
| j45 wrote:
| 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.
| ipaddr wrote:
| 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.
| DonnyV wrote:
| 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.
| meiraleal wrote:
| 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.
| kevincox wrote:
| 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.
| sandreas wrote:
| 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.
| rnavi wrote:
| a good blogpost from a16z : https://a16z.com/usage-based-pricing-
| rule-of-thumb/
| Eridrus wrote:
| This was surprisingly insightful, thank you!
| brudgers wrote:
| 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.
| clay_the_ripper wrote:
| 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.
| brigadier132 wrote:
| > 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.
| tiffanyh wrote:
| _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.
| pembrook wrote:
| 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.
| cpncrunch wrote:
| 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.
| memset wrote:
| 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.
| mcmcmc wrote:
| 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
| mateuszbuda wrote:
| 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.
| telepathy wrote:
| Residential IP bandwidth is a commodity priced per GB. The rest
| is available OS for free. This isn't a SaaS exactly.
| matt-p wrote:
| 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.
| brycelarkin wrote:
| 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.
| pm wrote:
| 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.
___________________________________________________________________
(page generated 2024-05-18 23:00 UTC)