How to choose correct pricing model for SaaS service?
Hello PH Community! Sorry for such a LONG message =( I'm really struggling with my pricing model. In September I launched my product here, on PH, and got initial feedback and users. Now I want to polish everything, add new features, make my product more mature. One of the problems is pricing. Not an advertisement, but here how it looks right now: https://pingr.io/#pricing --------------------------- In the uptime monitoring world, there are few pricing models that are common: Limit only monitors number & have subscription plans Here you have something like 1. Up to 5 monitors - 5$ 2. Up to 10 monitors - 10$ 3. Up to 20 monitors - 15$ 4. ... Limit number of monitors & features For example 1. Basic. You have up to 5 monitors and basic features 2. Pro. You have up to 20 monitors & SSL monitoring 3. Premium You have up to 50 monitors and status pages Less common, but I went to this model. Based on requests usage Here you can add as many monitors as you want, and you can use all the features, but you pay only for request usage. E.g., you added 1 monitor and set up uptime check frequency to 1 minute. 1 request costs 0.00012$ (as an example), and eventually, you pay something like $0.52/month for this monitor. What I'm asking feedback for I found the pay-per-usage model is pretty appealing. If users use my servers a lot, they pay more. Otherwise, if they have few requests per month, they almost pay nothing (0.01$), but they don't use the service much. Pros: - I can add new check types, e.g. SSL check, performance check, some other ideas too, which may cost more - I have more control over server usage. I can approximately know how many requests 1 server can handle, and thus I can calculate 1 request price which should be profitable - I can have a special price for large companies since I can setup any request price for any user Cons: - Not a big con, but might be confusing: I ask for a $1 minimal fixed price, because I need to cover the minimum fee for my payment processor and I cannot charge small amounts of money. If user have to pay 0.6$, then it might turn out that half of the price will be the commission - The model assumes that I'll have a lot of users who pay small amounts of money. It worked well for updown.io. But the support will be hard One way: 100 users pay $10, you get $1000 another way: 1000 users pay $10, you get $1000 But it's hard to support 1000 users. On the other hand, it's easier to make your app popular. ------------ Another question is the billing cycle. I decided to go for Digital Ocean model, when I charge everyone at once, on the first day of the month. So, if a user subscribes on 29th, I charge him in two days, which is a bit unfair. But for me, it looks like it's easier to maintain, rather than charge users in 30 days after they subscribed. So what do you think? Previously I had 3 plans and got quite a lot of complaints that it's expensive. P.S. I know that there are free solutions, but I insist that they usually don't include all the features you might need