Keep your pricing Simple, Stupid
When we released Liteflow out of beta a few months ago, we decided to operate with a Pay as you go pricing. We wanted something honest and transparent for the users, so it looked like the right choice.
The months passed, and we struggled to engage users with our product. Then we decided to call all developers we know to test it and provide feedback to get some insight. From that, we learned the first pain point was not even in our product but in our communication.
Nobody was understanding our pricing.
Without even knowing it, we created an effect of information overload.
To be 100% open and transparent, we decided to detail each of our services' pricing like Firebase or AWS. We displayed how much cost a task per invocation, second, and kilobyte. It was already a lot of information, but we added even more complexity to it by showing at the same time the amount of free usage and the task's cost details.
We tried our best to display it the most precise way, but in the end, it was way too much information for a user to analyze.
By the way, we didn't even have a calculator, so they needed to do the math by themself to know how much it would cost them. Let me tell you that if a user spends 10 minutes on your pricing page, there is a problem.
Now that we knew where the problem was coming from, we decided to rethink our strategy and switch to packages. Removing all the overwhelming information and focusing on what was necessary for the users will take them less than a minute to decide.
That also allows us to be way more flexible in marketing/sales as we can now put a precise price on our product. We will also be able to beta test our pricing to see what people are ready to pay for it.
From this experience, I learn that, for small actors, a Pay as you go pricing will be the most complicated and overwhelming solution you could choose. Even if you think it's the most appropriate solution for your future users, it could stop them from signing up.
Most people want something simple and straightforward, something they can analyze in a minute and decide. When it's time to think about a product's price, even if this product is complicated, they don't want to spend their time trying to do your job: telling them how much it costs. You should provide them with few options, easy to compare and display a precise price of how much it will cost them. Of course, don't block your users. Let them upgrade or downgrade from each packages depending on their needs.
Our next step is to monitor our number of new signups and how our users interact with the pricing. We already got some feedback about it that comforted our decision.
I can tell you one last thing, I already added a note on my desk: "Keep It Simple, Stupid".
Very interesting...
We are still based on a 'pay as you go' model (per signature and that's it).
Clients understand it quite well and that's fine.
However... the churn rate is incredibly hard to calculate.
Thus, we are going to change our pricing a little bit.
I found that Sendgrid is doing it quite well. But their customers based are 'nerdy' so complexity isn't a topic for them I guess.
If you find the perfect model, let me know :p
I like Sendgrid's pricing too, I think it's smart the way they display it by plans with the calculator integrated at the top. Even if it's still a bit overwhelming when you reach the features part.
Your pricing is pretty clear congrats on that ;)
I think I should have insisted more in my post that our problematic was mostly related to having something based on the cost of each services. Really similar to Firebase or AWS. For a user that's means guessing how much it will cost them without being able to have a clear overview of it. There is too many data that needs to be detail.
I thought too that having something a bit complex won't be an issue for developers. But after few months, doing researches online and in real life, I started to think that the less time they spend juggling with your pricing the fastest they will start using your tech.
My point of view is really related to our target and the kind of solution we provide with Liteflow, of course a clear pay as you go could work just fine for other businesses ;)
Copying AWS's pricing is a terrible idea because there are entire companies whose job it is to help you understand AWS pricing. You might think you're providing value by making pricing flexible, but you're just going to drive customers away!
Exactly you're right!
We were thinking at first that using Plans instead of Pay as you go won't be flexible enough for our target. Because we wanted to allow developers to pay only for each resource they use.
But at the end it was just driving them crazy ^^
Great insights here Emmanuel 👏 Using a pricing convention that is easy to understand and "normal" is almost always the best way to launch and grow in the beginning. Until you have more info on usage, customer feedback, growth, churn, etc it's usually not a good idea to create unique pricing models or over complicate it with feature or usage segmentation.
I couldn't agree more with you ;)
We learn from our mistakes haha
For sure if I have to do it again I will go first with a Plans pricing to bootstrap the growth.
I'm not against reintroducing a Pay as you go system in the future.
Like you said using a pricing convention easy to handle for the target at the beginning of the project seems to be the right choice.
This comment was deleted 4 years ago.