Woot Journals: How to decide pricing plans for an open-source product?

A blog about how Chatwoot pricing has evolved over time

TLDR: Start selling services, identify the value you provide and decide pricing plans based on it.

In this blog post, let me describe how we make our pricing decisions at Chatwoot. This post should be more relatable for open-source products, rather than opensource libraries or frameworks.

Most of the people whom I talked to described to me a value-based pricing framework which didn't make much sense to us, at that time.

Yes, SaaS businesses need to identify the value it provides to the user and price it correctly. But, how do you know what features or services are helpful, and how it improves the customer's businesses during your early stages?

You don't! There is not enough information about how people are using your product and what they like about it. Alternatively, you can take a look at the competitors and see how their pricing plan works. This decision becomes even more complicated when you have an opensource product.

The Chatwoot pricing story

When we started Chatwoot, We had two types of paid offerings in mind.

1. Chatwoot Cloud: A SaaS version where customers would pay for the features Chatwoot provides.
2. On-premise Plans: Support plans for On-Premise Chatwoot installations, which gives the users more flexibility and control over the data.

Seeing the introduction of data privacy regulations like GDPR and CCPA, we started with on-premise plans initially. We decided to adopt an effort based pricing model. We were not charging for the features, but were charging for the support we offer. It was a comfortable option to start with. So we started selling the support plans for installation and upgrades.

We estimated a 30-60 minutes worth of manual effort every month for a client with the automation we had in place. We started with a base plan of $20 per month. It was an experiment to see whether people were willing to pay us, and it did work. People started buying our support plans. Later, we figured the effort put vs margin we get is pretty slim, so we updated the pricing plan to $49 per month.

Soon, people started asking for customizations, custom integrations, branding etc. We introduced a new plan with $299 per month, which would provide additional customizations and priority features requests. This offering worked for a couple of customers. Later, when we looked at the effort we put into these custom installations vs the value people were receiving, the margin seemed unbalanced. It made us reevaluate our pricing plans. We reworked our pricing plans to introduce three different plans at $299, $499 and $999+ per month, which is what we have in place now.

What we learned ?

All these times, we have never asked our existing customers to pay more. They continue to be in the same plan they signed up. The revisions applied to new customers only.

This approach has given us enough time and space to understand what people like and what they don't. It also gave us insights on how people use our product. There is less churn compared to conventional SaaS business where people close the account the moment they start experiencing problems.

As more companies are planning open-source as their GTM strategy and the market starting to become more aware of on-premise support services, it has become relatively easier to sell these support plans. To price a product, you need to identify the value you provide. And to get there, you need customer adoption with a feedback loop. A support based pricing model fits well for this.

We are still learning new lessons and fine-tuning these pricing models. And we will continue sharing as we chug along 😃.