The landscape for headless CMS has grown vastly over the last few years. With that, it’s been interesting to see how content services approach pricing their systems. With several different approaches and types of pricing, here’s a breakdown of how to evaluate the different pricing models we see in the marketplace.
Pricing Models for Headless CMS
With lots of different opportunities for pricing headless content management systems, we’ve narrowed down the three most prominent pricing philosophies to be based on features, content entries, and bandwidth. Most of the time, content management services will approach their pricing with a combination of these, but by and large these are the differentiators we’ve seen.
1. Pricing Based on Features
Pricing models based on features is one of the most popular ways to segment tiers of a headless CMS. On a sliding scale, the smaller projects get less features up to full enterprise, which has access to all features the CMS has to offer.
Pay for the tools you need. If your project doesn’t need certain business-grade features, you don’t have to pay for them.
Less clutter in the platform.
Building a proof of concept in a smaller tier may not be accurate, as there is not full access to the platform.
Limited access can be detrimental. As projects morph, you may need to upgrade into a more expensive tier just to gain access to new tools.
Questions to Ask
Can I unlock features that I need as I grow, or do I have to upgrade to the next tier?
How do I upgrade to unlock more features?
I figured out that I don’t need all of the features I once thought I’d need. How would I downgrade?
Can I try features before buying them? What is the grace period?
2. Pricing Based on Content Entry
Another pricing model that appears to make sense on the surface is pricing for content models or content entries. The size of a project is largely defined by the number of content entries, rows, or records in a project. As such, pricing corresponds directly to the number of content entries in a platform. Before committing to a headless CMS that prices based on content entries, consult with a solution engineer to ensure your content is accurately quoted.
Pay as you grow. As projects grow, so too does pricing correspond directly.
Extremely predictable and controllable. Your team knows when they will be entering more content according to a content calendar, so you can expect price increases accordingly.
Discourages use of the platform. The more content you enter, the more you will be charged. So, teams tend to be judicious to a fault so as not to enter too much content in a system that charges them more.
Estimating content models, types, and records can be difficult and fluctuates.
Questions to Ask
What are the limits on content models, types, and entries?
When exactly am I going to be at the next pricing tier? (Ie, can you only add 10 more content models left in your plan, etc.?)
If I delete content records or modify content models, does that count against the limit?
3. Pricing Based on Bandwidth
Pricing based on bandwidth largely corresponds to the data transfer in requests, whether they be JSON requests, media requests, etc. This pricing model is for projects big and small to be charged according to content demand rather than content entries.
Pricing corresponds directly to success. As a project is more successful and gains traction, you will likely be making more sales.
Increases can be predictable based on seasonality of your business.
Based on demand. If a piece of content goes viral, you may have to pay more to cover those costs.
Questions to Ask
How many requests translates to page views or traffic?
If there is a spike in requests one month, what are the overages?
4. Pricing Based on Users
Some content systems price largely on the users in the system. This can be ideal for smaller, one person projects. Something to consider when evaluating a CMS that bases its pricing on users in the system is the pricing of any external services (delivery, rendering, page views, etc.) in order to keep in mind the total cost of ownership of a system.
Pricing correlates to the number of hands in the system: the more employees in a project, the larger it likely is.
You must be judicious when including people onto the license as each seat costs additional.
Adding additional developers in the system may cost much more than expected, even if they’re temporarily hired to get a project up and running.
Questions to Ask
Am I able to temporarily add users to complete a project?
What happens when I have reached the user limit: can I buy single additional seats as needed, or do I need to purchase a package of seats?
Am I able to limit the permissions of users in the system, and if so, does that affect pricing? (Eg. does having 10 developers cost more than 10 content editors?)
If I delete users, will I able to re-use those seats in the future?
5. Open Source Headless CMS
Open source licenses are free for public use. These must be self-hosted, so be sure to consider that when figuring out total cost of ownership of a CMS.
Community benefits: there is likely a community of developers that contribute to the project.
Hosting, delivery, CDN, and other aspects may need to be configured, so “free” is likely not really free.
Open source means you will likely have to rely on the community for support. The other option would be to source a skilled implementation specialist.
Open source software can be challenging for business applications. When there’s a need to start building custom software on top of a solution create a “better” solution, the potential for loads of IT management and technical headaches grows.
No guarantee that the vendor is stable and the project will continue to grow.
Questions to Ask
What are all of the things I need to consider to calculate total cost of ownership?
How will we receive support on our projects? Is the community a good option, or do I need an implementation specialist?
How long has this solution been around? How many contributors are there?
What sort of configurations do we need to make to our business process to adapt to this open source software?
Pricing Questions to Ask a Headless CMS Vendor
Of course, when evaluating pricing of different vendors, there are a lot of questions to ask to ensure you’re comparing apples to apples for your project.
Is pricing monthly or annual? Are there annual discounts?
What kind of support plans do you have? Are they included or separate?
When the time comes, how do I upgrade my account?
How can I see when I’m pushing the limits on my account? Will I be notified before going over?
Am I able to gain access to certain features without paying for the next tier? Can I unlock features as they’re needed?
If I go over my limit (content or bandwidth), what are overages like?
What does reporting on my limits look like? How often am I able to see those reports?
Asking these questions will help you evaluate if the headless CMS vendor is right for your project not just today, but as you grow and for the future of your brand.
Introducing Pricing Based on Success
Since opening up the platform to allow users to create a free sandbox, our approach to pricing is largely based on brand’s success. We decided not to limit the platform based on size of project (to us, that seemed counterproductive) or content records (we want you to go content crazy in Zesty.io!). We made pricing easy and scalable based on your success, whether you’re launching a small project for a hobby, building out a POC for your business, or embarking on digital transformation at your enterprise. At Zesty.io, we’re ready for your success and believe in your ambitions, and our pricing reflects that.