The key takeaway seems to be that their whole pricing scheme is based on customer and potential customer feedback. Interesting that they did not mention the competitive landscape and pricing schemes of others.
Because we actually didn't take that into account. Which meant we became too inside->out focused. But the overall point is, that there's a lot of wisdom out there on SaaS pricing, it's still difficult to get right.
Externally I'd say the community on IndieHackers has been a big help.
Second, but this came back to bite me, I asked many of my closest "colleagues" about their thoughts on pricing. All consultants within software development, which is generally priced higher than the broad average of freelancers - And this isn't intended specifically for developers, but anyone who's starting out.
The key takeaway is that they built constraints on the wrong place (prospects vs clients), so they are revisiting their pricing and constraints. It's a good example of listen to your customers.
Looks nice, do you have example how invoices look like? How about the legal requirement (in my jurisdiction) that invoices have consecutive numbers, do you allow to set that number (so it aligns with invoices not through your system).
Yes sir - So that if you've sent 5 invoices via another system, you can bump it and have it restart there. This is under your Profile, but you're the 2nd person to ask so I might move it into the Create Invoice Dialog.
When I was starting out as an independent consultant, I'd manually increase invoice numbers by a semi-random number (instead of +1), so it looks like I had many invoices/clients. Later I switched to a less predictable invoice format like "20220111-01".
I don't know if fudging invoices numbers was helpful, but I'm pretty sure that sending "invoice+1" to the same client several times in a row is never positive signaling for independents (at best, it's neutral if no one looks, but it could be negative).
I recall doing the same some 15 years ago :) I'll add a setting for increments which can be an int or Random. It won't be viable everywhere, but some will hopefully find it useful.
Good article. Most of the time the lesson learned is we doubled our pricing and our revenue doubled and customers are just as happy as before.
I've seen this touted on twitter and indie hackers so many times it makes me wonder sometimes if this actually works or is it just some advice that people are copy pasting.
It works, as long as you're charging more as your customers get more value from the software.
I went from charging $9/mo to charging $30/mo in 9 months of running an uptime monitoring service, and my customers these days monitor actual business websites/apps, rather than minecraft/gaming servers.
I didn't - existing users stayed at the cheaper price, some ended up churning (as the direction the product was going in was different to their expectations), new users only ever saw the new price.
I think if you think about it as 'I could be making more money off of these people' it can be a bit of a mistake.
In my old neighborhood we watched a restaurant break away from a franchise, go through a bunch of upheaval, triple in size, take building damage from a freak accident, and open a second location. Practically every time we went in there, if the owner was in the building he would come out to say hi to my partner, myself, and anyone we were dining with. Occasionally he brought an appetizer.
We were some of his oldest regulars. He didn't make more money off of us than anyone else at a table (maybe his staff got slightly higher tips), but we helped get him to here. So did your old grandfathered customers. Without them you wouldn't have your business loan or your VCs. You've made plenty of money off of those people. Stop thinking of them as a number. You can't measure your old customers purely by $/request/s.
Most of the time you want to grandfather your original customers in so they keep the same price. Once strategy I did was I broke my product "Original" into two parts "Primary" and "Add-on" with their own prices.
My customers got the old pricing on the new "Primary" service, so they were happy. But did not get the new "Add-on" which included lots of new features and updates to a slice of the "Original" product that they loved. They could continue using "Original" but it was no longer maintained and generally poorer quality. So many people added the "Add-on" to their subscription too. My revenue doubled.
You're saying "Primary" was a downgrade from "Original" at the same price?
What works best here may be field-dependent. "Poorer quality" is not acceptable in some applications, where it directly affects their bottom line. So once the degratation and reliability issues start, the older version might as well be cancelled. Until I give them the hard "break-up" message, these are the people bugging me constantly. Once they have a solution that does what they need at a price they love (which becomes a permanent price ceiling for some), there's on graceful way out.
I also have the problem that "no longer maintained" fairly quickly (matter of months perhaps) progresses into "no longer working" without some level of maintenance (which grows as components become increasingly changed and deprecated). So it's a delayed cancellation anyway.
They are pricing the product to align with 1 hour of a freelancers time. By saying 20 euro per month instead of 30, they increase their market to include the freelancers who work in the 20-30 euro per hour range. Not saying I agree with this logic, but this is the why they shared.
That might be the rationale to pick 20euro but that does not explain why they felt they had to lower prices (and they also lowered the top tier plan), which would be the most interesting IMHO.
The top tier reduction isn't very scientific. We had 99% of our paying customers on the middle-tier and we engaged a couple of them asking how we could improve the top tier to motivate them to try it out. All of them said that 60€/mo was higher than what their gut would allow them to pay.
In addition, we allowed Basic customers to also invoice by creditcard or subscription, which was the main feature requested for Professional. Since isn't not exclusive to Professional, that does lower the total value of that tier.
I expanded a bit on this in another comment, but these essence is this: We set the original prices based on our own hourlies and those in our network. Since launch, we've had considerable feedback from other industries where the average hourly is much closer 20€.
Basically, if you can't pay your own bills, I don't want you paying for ZimTik.
In addition, the customer gate was prohibitive for landing customers and the 30 days to send out your first invoices was stressful. The combination meant we had to lower prices and include invoices without the time-constraint.
A few years ago I attended a SaaS pricing discussion and two of the key insights that emerged were:
* For companies that gated based on usage, free/trial users were much more likely to make the transition to a paying customer. For companies that gated on features, free users tried to find all kind of ways to get things done without paying for the additional functionality.
* In the early days of many companies, most of the features of the product were given away for free, with just a a handful of features gated into premium plans. As companies grew, they realized that many of the features they should have gated, were now free, leaving little incentive for the users to convert.
Thank you for sharing, I think those insights are correct.
We have currently a few features where it's painfully obvious how to cheat the system to gain higher-tier functions. I wont change that, because if you're that strapped for cash that you'd rather cheat than pay 20€, I'm going to look the other way and hope that things change for the better for that person.
lbj, I agree. In my current SaaS app, I have a few customers that consistently try to take advantage of the billing grace behavior to save peanuts by canceling/re-subscribing/canceling/re-subscribing to try to fool billing system. Much as you, I've learned to let that go and hope for a change in behavior in the future.
To try to combat this issue in another app[1] I'm involved in the pricing packages are tiered at 5 SKUs / 200 SKU / Unlimited SKUs. As the customer grow, the driving function of plan upgrades is the volume of SKUs they work with. They also get extra features to better support operating at the higher volume. You don't get high volume features with the 5 SKU plan... We'll see how this approach shakes out.
Very glad to hear that I'm not alone in this line of thought.
Keep us posted on your SKU success. I wont pretend to be a wizard in the area, learning as I go along so stories from other ventures are a big inspiration.
36 comments
[ 2.6 ms ] story [ 85.7 ms ] threadExternally I'd say the community on IndieHackers has been a big help.
Second, but this came back to bite me, I asked many of my closest "colleagues" about their thoughts on pricing. All consultants within software development, which is generally priced higher than the broad average of freelancers - And this isn't intended specifically for developers, but anyone who's starting out.
A finally reading everything I could find online, like https://www.cobloom.com/blog/saas-pricing-models# - But as you can see ultimately we didn't follow these strategies too closely.
We currently have 2 templates for invoices, but will add more in the future.
Serial no's are consecutive and you can set when to start the series, so if you're at 888 now, just punch that in and we'll increment on that.
Thanks for poking :)
I don't know if fudging invoices numbers was helpful, but I'm pretty sure that sending "invoice+1" to the same client several times in a row is never positive signaling for independents (at best, it's neutral if no one looks, but it could be negative).
I've seen this touted on twitter and indie hackers so many times it makes me wonder sometimes if this actually works or is it just some advice that people are copy pasting.
I went from charging $9/mo to charging $30/mo in 9 months of running an uptime monitoring service, and my customers these days monitor actual business websites/apps, rather than minecraft/gaming servers.
In my old neighborhood we watched a restaurant break away from a franchise, go through a bunch of upheaval, triple in size, take building damage from a freak accident, and open a second location. Practically every time we went in there, if the owner was in the building he would come out to say hi to my partner, myself, and anyone we were dining with. Occasionally he brought an appetizer.
We were some of his oldest regulars. He didn't make more money off of us than anyone else at a table (maybe his staff got slightly higher tips), but we helped get him to here. So did your old grandfathered customers. Without them you wouldn't have your business loan or your VCs. You've made plenty of money off of those people. Stop thinking of them as a number. You can't measure your old customers purely by $/request/s.
My customers got the old pricing on the new "Primary" service, so they were happy. But did not get the new "Add-on" which included lots of new features and updates to a slice of the "Original" product that they loved. They could continue using "Original" but it was no longer maintained and generally poorer quality. So many people added the "Add-on" to their subscription too. My revenue doubled.
What works best here may be field-dependent. "Poorer quality" is not acceptable in some applications, where it directly affects their bottom line. So once the degratation and reliability issues start, the older version might as well be cancelled. Until I give them the hard "break-up" message, these are the people bugging me constantly. Once they have a solution that does what they need at a price they love (which becomes a permanent price ceiling for some), there's on graceful way out.
I also have the problem that "no longer maintained" fairly quickly (matter of months perhaps) progresses into "no longer working" without some level of maintenance (which grows as components become increasingly changed and deprecated). So it's a delayed cancellation anyway.
Spotted a minor typo in your bullet list:
> Free accounts are no longer limited 20 customers
I'm guessing that's meant to be "limited to 20 customers"
Were they more expensive than the competition? Was their conversion rate poor because of price? Are they seeing better revenue with the lower prices?
In addition, we allowed Basic customers to also invoice by creditcard or subscription, which was the main feature requested for Professional. Since isn't not exclusive to Professional, that does lower the total value of that tier.
If you disagree with logic, please let me know :)
Basically, if you can't pay your own bills, I don't want you paying for ZimTik.
In addition, the customer gate was prohibitive for landing customers and the 30 days to send out your first invoices was stressful. The combination meant we had to lower prices and include invoices without the time-constraint.
Hopefully we hit the mark this time.
* For companies that gated based on usage, free/trial users were much more likely to make the transition to a paying customer. For companies that gated on features, free users tried to find all kind of ways to get things done without paying for the additional functionality.
* In the early days of many companies, most of the features of the product were given away for free, with just a a handful of features gated into premium plans. As companies grew, they realized that many of the features they should have gated, were now free, leaving little incentive for the users to convert.
Hopefully this helps someone.
We have currently a few features where it's painfully obvious how to cheat the system to gain higher-tier functions. I wont change that, because if you're that strapped for cash that you'd rather cheat than pay 20€, I'm going to look the other way and hope that things change for the better for that person.
To try to combat this issue in another app[1] I'm involved in the pricing packages are tiered at 5 SKUs / 200 SKU / Unlimited SKUs. As the customer grow, the driving function of plan upgrades is the volume of SKUs they work with. They also get extra features to better support operating at the higher volume. You don't get high volume features with the 5 SKU plan... We'll see how this approach shakes out.
[1] https://fnskustudio.com/pricing
Keep us posted on your SKU success. I wont pretend to be a wizard in the area, learning as I go along so stories from other ventures are a big inspiration.