The Right Price
As a startup that has been running a SaaS app for a while now, we’ve had our fair share of hiccups when it comes to billing and payments. In this post we’re going to share some of the things we have learned over the years. While choosing a pricing model may seem like a no-brainer, once you get down to it, it’s really not as simple as matching cash flow and expenditure.
Which subscription model?
Choosing a subscription model is a business decision that needs to be taken after considering the nature of your intended cash flow, your application’s features and and how your target audience can best make use of them. There are also, it turns out, several other factors that should be taken into consideration as well. This is something we found out the hard way.
We developed CurdBee to scratch a personal itch. When we took the decision to go public we decided that freemium would be our business model. Also, at the very beginning we rightly understood that following a model based on base subscription price and a modular charge for features was the best way to go, especially considering our target audience of freelancers and SMEs. Except for a small portion, most of our user base needed only a few features.
What each user needed differed, of course. Since we wanted to keep costs low and charge users only for what they needed, modules were targeted at different use cases and based on our cost structure we decided to price individually for the base subscription and all modules involved. For the small portion of users that needed all the features we offered, once in a while we packaged the whole app as a bundle and gave it out at a discounted price.
After consolidating the product, the first subscription model we chose had two billing cycles. Firstly, we had a monthly pricing plan which had a fixed cut off date, the 1st of each month. For this model we charged the base subscription charge in advance and module charges in arrears. The idea was to let new users have a taste of the product for the least possible cost and let them then decide if they wanted to continue their subscription or not. The second pricing plan we introduced was a yearly one, with both the base subscription and modules charged in advance. This plan targeted long term users who wanted to avoid the hassle of monthly payment charges.
To be simple, or flexible, that is the question.
As time passed we saw our yearly pricing plan was working fine. The monthly plan, however, kept giving us headaches. As our user base kept growing, charging by the month also became more complex. The fact that we were charging twice a month was giving us nightmares when it came to reconciling/auditing our monthly revenue stats. While calculating prorated amounts for use cases like when a user joined the app in middle of the month and left before the end of the same month were challenging, we managed it pretty well.
The real issue was when such a user’s payment failed when leaving the product. When there was a payment failure for a leaving monthly user, we were sitting ducks because we had no option other than to bear the loss. The user had already used the product and left and there was nothing we could do. If it was just once or twice it was fine, but we noticed that some users were doing it as a scam and of course we didn’t like that one bit.
The solution was obvious. We had to change our pricing model.
Effective last December we started charging in advance. Our monthly pricing model is fine now and our yearly works very well apart from a somewhat high credit card failure rate because of the long billing cycle, but that’s for another time.
So to get my earlier point, it’s not just your business model and your app roadmap that needs to be considered when choosing a subscription model. Ultimately, a subscription model will be a trade-off between flexibility and complexity. This is a choice you will have to make, so be sure you’re ready!
