Many companies and organizations are considering whether to develop their next website on a traditional CMS or a headless CMS. This is not a surprise with the growing popularity of headless CMSs. And yes, a thorough comparison is time well spent because there are many differences between the two types of systems. Not only in use and implementation, but also when it comes to costs.
In this article we emphasize on the latter: what are the factors that determine the real cost of a headless CMS implementation?
WordPress is probably the most well-known traditional CMS of this century. One of the biggest advantages of WordPress is that it is free of charge, at least you don't have to pay a license fee to use it. Behind WordPress is a community that takes care of further development and improvements. Although WordPress is free, you should realize that you can incur considerable costs for hosting and maintenance of this CMS.
Unlike WordPress, most headless CMSs are (further) developed by a (SaaS) vendor. The investments in the software are covered through licensing costs. New developments can be made with the license income.
Often headless systems have a freemium model to lower the threshold for new customers. In many cases you will only pay if you actually start using the CMS (on a larger) scale. You often pay per user, module or per use (eg API requests). This can increase your license costs fairly quickly.
If you have set up the (headless) CMS, you will not switch to another CMS quickly, so make sure you get a good understanding (in advance) of the license costs and which variables cause a possible increase. Don't assume that if you don't pay anything for a traditional CMS now, you will also find a headless CMS that you can use for pennies on the dollar. Often the license prices of a headless system that is used by several (marketing) employees and receives many API requests will cost a minimum of thousand of euros annually.
The fact that a headless CMS builds on a different vision than a traditional CMS is strongly reflected in the implementation. Here you often see a conflict arise. A headless CMS is purchased because the vision seems future-proof, but if the organization is not ready for an omnichannel content strategy and continues to work 'traditionally', a headless CMS is of little use. The implementation has two factors that determine the cost price:
1) your internal employees and their knowledge and skills,
2) the expertise you need to purchase for a successful implementation.
What expertise do you need for a Headless implementation?
I assume that you want to implement a headless CMS for an omnichannel content strategy. Omnichannel means that a company serves a seamless customer experience across all channels (offline, online, app, etc) making it seem like one channel. You often see that organizations buy a headless CMS, but implement the implementation in a traditional way.
With a headless implementation you need at least two roles or functions more than with a traditional implementation:the content architectand the content curator.
The content architect helps organize content and advises the best approach to structure the content so that it can be easily reused in different situations and on different channels and devices.
The content curator collects, selects and filters the content and places it in context. Content curation is increasingly needed, because companies produce a lot of content, but a lot of valuable content is also lost as a result.
There is so much information these days and most consumers don't have the time (or the inclination) to dig through all this content. That is exactly what the content curator focuses on. They look at what is relevant to the target group, what content they care most about and then present it in a perfect arc.
A mistake many companies make is to view the curatorial role as a coordinating role. However, the curator actually has strategic skills to analyze the connections between content and to know to which 'buyer persona' the content belongs and to determine where the content belongs within the 'marketing funnel'.
Few companies and organizations have the role of content architect and content curator internally. Within marketing and communication, content is still often seen as ordinary production work, while a successful headless implementation requires you to look at content differently.
If you look now to the other roles, they are quite 'traditional'. Think of: a (content) marketer, strategist, SEO expert, designer, developer, etc. If you do not have one or more roles available, you will have to hire them externally. Headless trajectories are often substantial in terms of impact in hours, so free up your budget.
Another factor that can drive up the cost of a headless CMS implementation is the need for customizations. A headless CMS gives you a lot of freedom for the front-end but because you can't just get to the source code of the CMS (there is a company behind it), you can't just make a few modifications to the system. So if you want to customize the dashboards, buttons, functions, etc this isn’t as ‘hack-savvy’ as a traditional CMS where you can access the source code.
In many cases you do not want this either, but if you have specific wishes about how a solution should work, it is wise to do good research into this.
This part isn't relevant to everyone, but we've seen it popping up a few times over the years: an app. If a company has its own app, it is often developed as a 'monolith' next to the existing communication (portal, website, etc). If a company follows the 'omni-channel content' philosophy, this app must 'suddenly' be included in the headless process. It is therefore better to think about this in advance than halfway or at the end of the process.
A website or app rarely stands alone, especially not within a headless CMS implementation. Often (raw) data has to come from other sources, or, for example, from a phased out CMS, a CRM system or a Customer Data Platform. The more integrations, the more hours you have to spend developing the integrations as well as any modules you need to purchase to make connections.
Check in advance whether a headless CMS can integrate through a GraphQL, REST API, webhooks and/or Zapier or Mulesoft. The more connectable a CMS is, the less time you need to spend on expensive integrations.
6. Hosting / security / upgrades
The last part concerns hosting, security and further development. If a headless CMS is also a 'hosted CMS' then hosting, security and upgrades are often taken care of centrally (multi-tenant). The costs for this are then discounted in the license price. In some cases you have to pay extra for use and hosting if you override the 'fair use policy'.
If you choose a 'self hosted' headless CMS, you will have to take care and responsibility of these matters yourself. This can have a significant impact on your budget. Security and cyber security is certainly an area that requires attention.