Let's talk pricing models...
Dan Edwards
11 replies
Hey Makers!
A friend of mine runs a small SAAS product with ~1000 users and is currently using per-user pricing, at a low price of $1 per user, no minimums or maximums, no tiers and has found great success with it.
This had me interested to find out which pricing models you've tried and found the most success with?
As a Maker, I've made products that use a free (ad supported) model, which worked really well but is becoming less trusted with the increase in privacy first products and can be hard to get advertisers that align with your vision/ethics (especially when you just need that $$$).
I have also worked on products that use a tiered pricing model but we had a hard time getting our initial users until we released a free tier.
From a consumer point of view, I personally find flat rate pricing/subscription to be ideal for me, because I know how much it's going to cost each month, regardless of the number of users.
I also use a lot of products that adopt the freemium model, which works great if you're able to offer me basic (but useful) functionality, and then upgrade to unlock premium features for a fee.
What is your favorite pricing model(s)?
What has worked / not worked for you?
And what do you like as a consumer?
Excited to hear your responses!
Replies
Opeyemi Obembe@kehers
Mailintel
@de What currently works for me: freemium model with recurring subscription based on features and not per seat. I tend to shy away from per-seat pricing because as a consumer I don't like it that much. What I have also noticed is that many times, additional "seats" don't really impact resources.
What hasn't worked for me:
- charging based on resource utilisation at the end of billing cycle. I have a service that is charged based on number of "events" processed within the cycle. What I have noticed is that some people won't pay after the period.
- Pay what you want. People will rather use/download for free or pay the least amount.
Share
@de A little different story here - I haven't been able to implement my pricing structure and verify that it would _actually work_ yet...but! whenever I do show my product to users, the pricing structure is always one thing they bring up. Nine times out of 10 I would say the pricing structure is a top two aspect of my product that they are excited about.
The way it works is it is based on usage - I like to say it as "it's pay to play, but the more you play the less you pay."
So a user sets a goal each month of how many times they want to run - say my goal is to run 20 times this month. Based on the number of times they actually run, the next month price is then prorated. So if I run 10 out of my 20 time goal, the price I pay is half of the full price. If the full price is $5 a month, then next month I would only pay $2.50. (10 runs / 20 runs * $5.00 = $2.50)
A couple of fun notes about this - for me, it hopefully keeps users around. It doesn't deduct the price or give money back _for the current month_. Instead it gets people hooked onto _the next month_. All that hard work of running 10 out of 20 times will save you money next month as you look to keep on running. A caveat is that there is a "minimum price" per month that it would never go below (a dollar or something).
Potential problems with this idea deal with how trying to predict month to month growth. Say there are 100 users. If none of them run for some reason and I charge at $5 a month, I would get $500. But, say _all of them_ hit their goal, then I would only be getting $100. There is a wide range of what the next month _could bring in_ because it is all based on how well users stick to their goals.
So there are tradeoffs as with all things. My personal goal with my product is to help people get healthier and think more about their health so I _actually want_ people to meet their goal...but that means less $$ coming in. A weird conundrum but everyone I bring it up with is fascinated by the idea. (If you are curious more about it, you can visit the pricing page here: https://harvy.app/pricing)
Product Hunt
@kevinguebert Thanks for the detailed response, Kevin! I actually love the idea of paying less the more you use the app! I'm with Vitality for health care and they have a similar model, where your premium renewal is affected by how active you are. You work up through different levels, which essentially rewards you with a lower price next year if you stay fit / get fitter.
They also implement something similar for rewards, you can get an Apple watch and pay £12.50 per month for it, or if you hit your exercise goals, you can get it down in price, all the way to free!
This works really well for them as they get a healthier member (which should mean they pay out less) and you get rewards and a lower premium. Double win.
I've not heard of anyone else adopting this model (I'm sure there are, and maybe someone else will highlight companies that do).
Excited for you and Harvy! Good luck and keep on making!
@de I would be interested in learning more about how companies doing this kind of model are doing. Is it sustainable or is it more of a "side" part that gets people interested? For example (I dont know much about Vitality), maybe the apple watch is pennies to vitality and is more of a perk for the users and Vitality is more focused on the health care insurance side. So does that mean that just the reward side is unsustainable? I'm not sure yet, it will definitely take more research!
@de, I'm only building my first service, so no personal experience, but found this quite interesting guide today https://stripe.com/en-ch/atlas/g... with lots of examples/different models
Product Hunt
@much_applied Super helpful article, thank you! As a consumer, do you find you prefer any particular model over another?
@de per-user services are paid from company's wallet, so it's not really tangent to me, as usual person I like free tiers, that ends on features(also monthly flat rates), that will be needed in future, when you'll use product to make something serious and potentially profitable on top of the use. But, I guess question is highly intermingled with the type of services/type of customers, otherwise it's some kind of pointing the finger in the sky
Softagram
@de Our learning so far is that it should be simple and known by buyers. We started to price Softagram first based on the amount of code (Lines of Code)/Month
But as a DevOps tool, the standard simpler way is to price is based on the value. Our value is based on how many users are participating in the development so we changed the pricing "seat based" (€/Seat/Month)
However with old code-base, there might be in-active developers, so currently, the "seat" is "Active Developer" (counts the ones that have done commits during last month).
In GitHub Marketplace our App is priced simple 22€/seat. On-Premise installation comes with "server fee" and gradually decreasing seat price.
Product Hunt
@tommi_tallgren Nice, this a great example of keeping your pricing simple. If I can work it out without having to open up my calculator app, that's immediately one less thing I need to worry about.
Thanks for sharing your experience :)