If you've been following my micro-SaaS guide up till now, we have covered finding and validating a business idea, and building a minimum loveable product to launch into the market.
But, your product can't go live without pricing plans. So let's get that sorted right away!
It is only prudent that we explore the most common SaaS pricing models before deciding our own.
The best pricing strategy for your SaaS depend on several factors, but most notably they depend on
Perhaps the most common way to price a SaaS product is to have a per user pricing model. Your customers pay per user, and with each additional user, they pay more.
Example of per user pricing:
Pros - It's common and easily understood by users, and revenue scales with higher adoption or growth of an organization.
Cons - Might limit adoption as users might share accounts or be apprehensive of adding new members of their team to your product, due to the per user cost.
Also very common is slab or tiered pricing. It's when a SaaS company gates certain usage limits, or features, or both. The best companies typically have 3-4 pricing tiers.
Example of tiered pricing:
Pros - Appeals to distinct customer bases, if done right. A small customer will pick the lower pricing tier, large customer higher tier. The cognitive load of selecting a pricing plan goes down. You or your inside sales team will also have a clear path to upselling existing customers when they outgrow their pricing tier.
Cons - If you have too many tiers, or if you split features without being thoughtful, you might create confusion in your customer's mind. They would be overwhelmed in trying to decide which pricing tier is right for them.
A pay as you go model works perfectly for certain products where the value derived increases almost linearly with increasing usage. This could be an API company where you can charge per API call. Or your product might aid customers in increasing sales and revenue, in which case you could collect a % of the revenue.
Example of usage based pricing:
Pros - Pricing scales with usage, which is great for you in terms of revenue. It's also easy for a new customer to get started, they only need to pay for what they use and they can quickly gauge how much their usage might be, provided the value metric you use to scale pricing makes sense.
Cons - Hard to predict revenue for you as a business, and hard to predict costs a customer.
A flat pricing model is like a buffet, pay a fixed sum for an all-you-can-eat experience. I personally think it's a good pricing strategy to adopt for the early days, given its simplicity and low cognitive load to arriving at a decision.
Example of flat pricing:
Pros - Easy to communicate, and hence easy to sell.
Cons - Someone whose usage is lower might want to pay less. Someone whose usage is super high might end up costing you too much.
Other than picking the right pricing model for your micro-SaaS, there's also additional strategies that lower the barrier for new users to start using your product.
Free plans work great if they attract and keep users who are likely to either:
If neither of these conditions apply to your micro-SaaS, including a free plan might not really benefit you in any way.
A free trial is perfect for your would-be customers to try out your product and its advertised features, especially if you are unproven and they aren't sure whether your product will deliver on its promise.
In today's time, free trial is considered a standard for almost every kind of product. And so users have a built-in expectation that you might need to satisfy.
The only thing to think deeply about is the free trial length. I've covered this in a later part of this post.
You can completely make your business work by being paid-only, and the benefits of it are manifold.
However, as a new micro-SaaS business I urge you to consider the free trial and free plan routes.
The primary reason? You are trying to do everything you can to lower the barrier for new people to sign up and use your service and give you feedback on whether you are solving a real problem, solving it well, and generally headed in the right direction.
Have the mindset that your first 100 users won't be the reason your SaaS makes it big and grows to a high MRR.
The first 100 users are validation that there exist 1000 (or more) others facing the same problem and needing your solution. Those 1000 is where you need to focus on earning from.
The literature on pricing models and strategies does not end here, but as you delve deeper, you enter the land of optimizations and smaller improvements.
I keep repeating this because it's important - in the early days, you want to keep things clean and simple, for you and for your customers. Not only that, you want to do everything you can to get users through the door and signed up.
Your objective should not be revenue optimization. It should be to cast a wide net before you have enough data and gut-driven insights to start narrowing down. And all the concepts discussed in this post so far are sufficient for you to achieve that simple pricing.
So how should you price your Micro-SaaS? Here's what I recommend:
Fewer options means lesser cognitive load. Customers only have to decide whether they want to sign up or not. And in case you have a free plan, the choice to be made is between two, hopefully clear, options.
A simpler pricing model with fewer tiers will enable potential customers of your product to get signed up quickly. And that's your primary objective during the early days.
If your product delivers increasing value to users the more they use it, then there's likely an axis on which you can build a scalable pricing model.
Zenmaid has nailed it here - they understood that the size of business run by maid service owners is determined by how many cleaners they manage. And so instead of having pricing tiers, gated features, or anything else for that matter, they simply included a slider that scales with the number of cleaners in their team.
The mental model for Zenmaid's customer to understand the scalable pricing is also very obvious - "I pay according to how big a team I manage? Makes sense!"
However, scalable pricing is not as simple as the above example illustrates. If you pick the wrong scalable axis, you might end up charging too little. Or worse, you might incentivize bad behaviour for your users.
Let me illustrate with an example (remember, this is a hypothetical) - in a parallel universe, Zenmaid's pricing could have scaled with the number of houses or clients served by the maid service. Seems straightforward right? You pay more if your business is bigger.
Well, here's how it might go down. Maid service owners would onboard all their cleaners to the software, as there's no additional charge for doing so. And then they would simply NOT log all the clients or houses they serve in the software.
This is because they are disincentivized from logging all their clients - after all, not logging means they pay less. And unless Zenmaid's product has a clear value proposition that increases with the number as a maid service owner logs more clients into the software (eg. accounting, invoices, etc.), their users are now incentivized towards bad behaviour.
$5/mo is usually too low, and it attracts people who aren't really serious about using the software. Worse, you might attract users who say "this should be free." These are not the users with whom you can build a business. In the early days, you don't want to attract non-users who waste your time and resources.
Jon of Bannerbear learnt early that a very low starting price attracted the wrong type of users, and has since adopted a clean and simple tiered pricing structure with a good starting price of $29/mo.
However, if you think your SaaS should be priced at a $100/mo, try to start at 1/4th of that. Start at $25/mo, which is a sufficiently high price point to attract serious users, but also low enough not to deter someone from trying your product in the early days.
The purpose of the free plan is to attract users who are likely candidates to eventually upgrade to your paid plans. If that's not the case for your SaaS, then you can skip having a free plan altogether.
If there is a viable way for you to cut down on features for a subset of users, or set usage limits that don't cannibalize the paid plans, then a free plan be right for you.
You'll have to decide for yourself if going free for the first few weeks can provide you that boost, and if yes, go for it.
In the early days, following the principle of keeping friction low, you might let users start a trial without entering their credit card details.
Again, this doesn't mean you never add that friction later. All these tiny decisions to keep friction low in the early days adds up.
Set the right trial length
When offering a free trial, bear in mind what is the right length of trial to offer. If you offer too long a trial, people might sign up but not end up using your product immediately, leaving it for later. If the trial period is too short, it might deter people from signing up at all.
The right trial length is one that gives your customers sufficient time to use your tool and experience its value proposition.
For the example we have followed so far - SaaS product to collect user feedback - an appropriate trial period might be 30 days. That's because it might take that long for your new users to setup your product in theirs, start receiving feedback from their users, and experience the full value of your product.
The pricing model in the screenshot below has nailed everything in terms of simplicity, and having a scalable axis to the pricing model. It's the best example that I could find which captures most of the points talked about in this post.
Let's unpack everything happening in EmailOctopus' pricing page:
If your SaaS product has similar characteristics as EmailOctopus, then I urge you to copy and adopt their pricing model for your own.
In case your SaaS does not have a scalable usage component, or you're not clear about which component scales with user value, then the easiest solution for you is to start with a a flat price.
Remember, this pricing is only to attract your first 100 users. You can always modify your pricing model later once you understand your users better and how they derive value from using your product. and modify it later.
Keeping that in mind, a flat price is simpler than a scalable pricing that scales on the wrong axis, as that would confuse and alienate your potential customers.
Hope you've got pricing for your micro SaaS sorted? If not, message me on Twitter or Email and share your questions.
The next step is to get out there and acquire your first 10 customers.