For those who missed it, last Tuesday we revealed Appwrite’s pricing plans. Many of you had let us know that you had been anticipating this moment, so it’s exciting to have reached this new milestone. Now these plans didn’t come to us overnight and have been a long time in the making, many months of research and consideration have gone into understanding the best price for our community. We are happy with the outcome and that we took the time to understand our community.
So what did we do over the past months? What made us come to these choices? Who was part of the process? In this blog, we will give some insight into our process and how we validated, what we believe, is the best pricing for the Appwrite Community.
Value Framework
We created a set of principles to guide us through the pricing process. We like to call this the “Value Framework,” as it focuses on delivering the maximum value to developers using Appwrite without compromising on the affordability and accessibility of our products and services. And this is what it looks like:
- Equally plan for being accessible to all and our continued growth.
- Make adoption easy and ensure the developer's growth and success matches pricing.
- The developer's success helps Appwrite grow and deliver better products.
- Features should be consistent across tiers unless they are clearly focused on enterprise.
- Focus on value-based profit. Limits should only be applied to usage. Not functionality.
- Be fair.
Now with this framework in place, we could take the next step: start with our research. We needed to know what the above framework meant to Appwrite users and the community.
Let’s dive into our research methodology.
Knowing, not guessing
One thing we wanted to really stay away from is assumptions. We need to know, and not guess. So for each part of the framework, we needed to come up with a set of questions that would lead us down the right path. We formalized these questions over three different surveys and one on one interviews:
- Understanding your project needs and how costs would affect this.
- What pricing models would be accessible to different developer needs.
- Getting real responses on the actual pricing plans.
- In-depth interviews to understand how you incorporate Appwrite into your daily work.
Overall we had a total of 410 respondents who helped us shape the pricing models. We interviewed over 30 developers online to get direct feedback and to understand how they used Appwrite. This gave us insight into how pricing could affect their work and really helped us understand where limitations should be placed and really should not be placed.
Business model
Another important point we wanted to challenge is the business model used in the backend service industry. The standard is a ‘pay-per-project’ pricing model, where you pay for each new project. We had our doubts about this as we felt it gets in the way of your ability to act on your imagination or ideation. We believe in creativity, value exploration, and learning, so not limiting the number of projects was an important factor for us to consider. So we challenged:
Pay per project vs pay per developer (those who use Appwrite)
Honestly, the results were tight. We asked straightforward questions about what you would prefer, which didn’t tip the scale. But once we focussed on actual usage, it became clear that having multiple free projects was needed for developers to explore possibilities. This does mean that if you collaborate with other developers on the same project, you will need to upgrade. It was the trade-off we made based on our framework:
The developer's success helps Appwrite grow and deliver better products.
We felt that, based on research, limiting projects would be a bigger blocker than limiting team size. Most of the organizations with multiple team members were commercial production projects that could afford an upgrade, whereas some of the individual developers with multiple projects were not in production yet. So for us, this business model is fair and better aligns with our values and mission.
And the reactions said enough.
Price
Choosing the right price is never an easy task, but with our values in mind, we knew that whatever we would pick, it would have to be fair. And with that in mind, we wanted to:
Make adoption easy and ensure the developer's growth and success match pricing.
So what did we do? We asked what price would work best for you. We had lower and higher prices, but the price of $15, per month was the one that nearly everyone favored and considered to be fair on both sides. We really appreciated the honest answers we received. It was amazing to see so many developers looking out for Appwrite’s future, and not just the best price for them. This really showed how the community turned up.
Listening to feedback
Overall, we got a lot of feedback for us to work with, but the most heard was: be transparent and keep Appwrite accessible and affordable, but also become a sustainable company for the future. We believe that with this pricing, we will be able to make this feedback come true. To add to this, we wanted to be sure to add a pricing plan that would support open-source maintainers, like Appwrite, once started, as they build out their product for the community to benefit from.
Conclusion: The beginning of a new dawn
A new and exciting era has begun before us as a community in which we reach new heights. We look forward to building out Appwrite and ensuring our mission to make software development accessible, developer-centric, and flexible by building with and for the open-source community.
And I think James Q Quick said it best. We are truly focused on the developer and we want to keep doing so for the future to come.
Top comments (0)