How We Defined The Pricing Model of Qovery

As a co-founder & CRO (running growth and revenue operations), this is probably one of the areas where I spend the most time thinking and experimenting at that moment. Indeed, we've set up a growth engine that is starting to pay off, the product usage per user is increasing significantly over time, and retention is improving. This is why pricing becomes a significant challenge for our company's stage.

I thought it would be helpful to write an article talking through the logic behind our pricing model and how we will continue to iterate in the coming months (I'll keep this article updated)

#What matters when it comes to pricing?

Before moving forward with any pricing strategy, you must do a little bit of homework:

Analyze your target audience:

• Who are you targeting? Are they price-sensitive?
• What difference will you make in their day-to-day? What will be your stickiness?
• How can you guarantee adoption?

Refine your product positioning:

• Is your software providing a solution that does not exist to a common problem?
• Is your platform based on the value proposition that no one else offers?
• Is the product going to blow the users' minds from the first few hours of usage?

So basically, understanding customer value should probably be the first consideration for your pricing model. It's not about features, not about what your competitors charge or even your costs.

Customer value is the perception of what your product is actually worth to customers, meaning whether they feel they got benefits and services over what they paid. These include product benefits or quality, values, experience and success in using the product, etc.

Like many, we started by doing what everyone says not to do: Give your product for free. This is probably excellent advice, but we ignored it (rightly or wrongly). Our goal was to get as many users as possible to maximize our learning and iteration rate. Each new sign-up and each active user told us a bit about the user/persona interested in our product, and the use cases people are looking for. As a result, trying to get an accurate understanding of what our customers value, and would value.

So far, this strategy has been quite successful for us because we've reached over 16,000 developers on the platform.

I can already hear you telling me that not charging customers is the best way to get irrelevant/wrong feedback. Well, you know what, you're absolutely right! While we had a pretty accurate understanding of how our users were using our product (thanks PostHog), we had no concrete and candor feedback on why users would pay. I think it's the worst thing that can happen for a startup (and often means its death)

Understanding customer value was our obsession at the time. And we knew we had to include the pricing component to validate (or not) what we had observed from thousands of users.

We quickly iterated by integrating a pay-as-you-go pricing experimentation into our plan, which was based on a consumption growth metric. This brings me to the next part 🙂

#Picking The Right North Star Metric

#

Your North Star Metric is your strategy, and your strategy is your North Star Metric. Choose wisely — Lenny Rachitsky

Picking the right North Star Metric and nailing it is so crucial if you want your company to reach its maximum growth potential.

It was a game-changer for us at Qovery.

For those unfamiliar with this term, the North Star Metric is the top-line metric that all company priorities are aligned around.

There are different categories of North Star Metrics:

• Revenue (i.e MRR, ARR...)
• Customer growth (i.e free/paid users, growth of the customer base,...)
• Engagement growth (i.e DAU, MAU,...)
• Consumption growth (i.e video with a view, messages sent, number of rides,...)
• User experience (i.e NPS...)

To qualify as a “North Star,” a metric must do 3 things:

• lead to revenue,
• reflect customer value,
• measure progress.

So, how to find your North Star metric?

1/ Start by asking yourself:

• Which metric, if it were to increase today, would most accelerate the growth potential of my business?
• What jobs are our users hiring our product to do?

2/ What to focus on would depend heavily on your business model, how your product grows, and its use.

For example, freemium team-based B2B products such as Qovery (and probably most of the DevTools companies), aim to grow through a bottom-up acquisition model. These businesses aim to hook free users with high product adoption and team members' invitations. Eventually, after businesses reach a certain usage level, they upgrade to a paid plan.

If we go back to the question: What jobs are our users hiring our product to do? Suddenly, it was apparent that the tasks our users were looking for were to deploy easier and faster. Yes, the deployment tasks would be our price metric!

So, we've chosen to maintain a laser focus on a consumption growth metric which is the number of successful deployments per week.

By focusing all the efforts on this metric, we could generate much better product adoption, relatively a higher engagement per user, and guess what... a better revenue.

Disclosure: We are still very early in this experimentation, so don't take this as a definitive insight.

But keep in mind that nothing should be set in stone. Expect your North Star Metric to change as your strategy shifts. It will evolve as you learn more about what brings the most value to customers, what aligns the whole team, and what achieves your ultimate vision.

ℹ️ I can only recommend you to read this resource about the importance of choosing your north star metric, with many examples from tech companies we use every day.

#How does our Pricing Model Works?

From there, we picked a price metric that scales with value (i.e customer value).

The more people need to deploy, the more value they get from Qovery, so it makes sense to base the pricing model on the deployment tasks.

So, we ended up with a per-deployment, tiered, freemium model:

• Free up to 100 deployments and 3 users, which is the perfect fit for what most small startups need, and allows larger teams and growing companies to test out the product a significant amount
• $49/month up to 300 deployments and 15 users, sufficient for most growing companies with a team of fewer than 100 people (we added some premium features such as Preview Environments). Notice that you can buy additional bulk of 100 deployments without being forced to upgrade your plan.
• $599/month up to 1000 deployments and 30 users with premium features ideal for larger organizations with security & compliance requirements.
• Custom pricing beyond that

So, charging this way (on a per deployment basis) would not only optimize willingness to pay, but it scales nicely with the value we provide.

As we are quite confident about the pricing model right now, the difficult task is to find the right price/unit balance. Is it $29 for 100 deployments? $49 for 300 deployments? 199$ for 300 deployments + premium features? Nothing is magic here. Just experimentation and data matter. My dilemma is mainly between the barrier to entry that the pricing can cause, and the depreciation of the product if the pricing is too low.

#How effective is it?

We just set up these pricing plans a little while ago, and we don't have a large enough customer base on these new plans. But we will know much more about how they work in the coming weeks, as we have been onboarding more and more customers since the beginning of the year 2022.

The most critical and counterproductive thing that could happen to us would be the lack of understanding or alignment with the value we offer. As a result, the pricing would reduce usage instead of increasing it. And this is what we will try to validate in the coming weeks

Pricing is not just a financial exercise. It should actually be an integral part of the marketing and product strategy. As mentioned above, your price sends a message to the entire market. It gives an indicator of product quality. Just look at the perception of high-quality products with their high price. The opposite is also true regarding the perceived quality of very cheap products.

The other thing to keep in mind is that your pricing needs to be predictable and simple. It could make it really difficult for new customers to predict how much the service will cost them. And especially in our market. This is often one of the points criticized in the pricing models of Cloud providers (like AWS) or hosting platforms (like Heroku).

While we've made some significant progress on the pricing, there are still a lot of optimizations to be done, especially to bring even more simplicity, transparency, and predictability for our users.

We are still experimenting with pricing and will probably try new things in the coming months.

I hope this sharing of experience has been helpful. There are many great resources out there talking about SaaS pricing that is worth checking out, but if I had to recommend one, it would be the one from the Stripes teams who shared 9 Tricks to Experiment with your Pricing Strategy.

#About Qovery

Qovery is the simplest way to deploy your apps on AWS and Kubernetes. As a developer, deploying apps on AWS is not an easy task. Plus, Kubernetes is the best container orchestrator but lacks simplicity for most developers. This is where Qovery comes in. Qovery makes it easy for any developer to seamlessly deploy an application in a repo to AWS - by empowering Kubernetes behind the scene. Learn more and watch a demo video here