6 factors that determine the price of a headless implementation

Many companies and organizations are currently weighing whether to have their next Web site developed on a traditional CMS or a headless CMS. Not surprising given the growing popularity of headless. If you compare both CMSs, you will see many differences. Not only in use and implementation, but also when it comes to cost.

In this article, we zoom in on the latter aspect: what are factors that drive the cost of a headless CMS implementation?

1. License

WordPress is probably the best-known traditional CMS of this century. One of the great advantages of WordPress is that it is free, or at least, you do not have to pay a license fee to use it. Behind WordPress there is a community that takes care of ongoing development. Even though WordPress is free, realize that you can incur hefty costs for hosting and maintenance of this CMS.

Unlike WordPress, most headless CMSs are developed by a company. The investments in the software are recovered through license fees. With the license revenue, new developments can be made.

Often headless systems have a freemium model to get started. In many cases, you only start paying when you actually start using the CMS (on a larger scale). You often pay per user, module or by usage (e.g. API requests). This can cause your licensing costs to rise fairly quickly.

Once you've set up a headless CMS, you won't switch to another CMS easily, so make sure in advance that you get a good idea of licensing costs and which variables will cause them to rise. Don't assume that if you don't pay anything for a traditional CMS now, you'll find a headless CMS that you can use for "next to nothing. Often the license fees of a headless system that is used by multiple contributors and gets a lot of API requests go into the thousands of dollars per year.

2. Implementation

The fact that a headless CMS builds on a different vision than a traditional CMS manifests itself strongly during implementation. This is also where you often see 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," you have little use for a headless CMS. The article "What is the value of a headless CMS when used traditionally?" explores this topic in more detail.

Implementation has two factors that determine the cost:

1) your internal staff and their knowledge and expertise,
2) the expertise you need to procure for a successful implementation.

What expertise do you need in a Headless implementation?

I'm assuming for a moment that you want to implement a headless CMS from an omnichannel content strategy. Omnichannel means that a company serves up a seamless customer experience across all channels (offline, online, app, etc) making it seem like one channel. You often see organizations purchasing a headless CMS, but doing the implementation in a traditional way.

In a headless implementation, you need two roles harder than in a traditional implementation: the content architect and the content curator.

The content architect helps organize content and recommends the best approach to structure content so that it can be easily reused in different situations and on different channels and devices.

The content curator collects, selects and filters content and places it in context. Content curation is increasingly needed because companies are producing a lot of content, but a lot of valuable content is being lost as a result.

There is so much information these days, and most consumers don't have the time (or the inclination) to sift through all this content. That is exactly what the content curator focuses on. Who looks at what is relevant to the target audience, what content they care most about and then presents it in a perfect arc.

A mistake many companies make is to think of the role of curator as a coordinating role. However, the curator actually has strategic skills to analyze the connections between content and know which "buyer persona" the content belongs to and determine where the content belongs within the "marketing funnel.

Few companies and organizations have the role of content architect and content curator available internally. Within marketing and communications, content is still often seen as vulgar production work, while a successful headless implementation requires a different approach to content.

If you look at the other roles, they are quite "traditional. Think: a (content) marketer, strategist, SEO expert, designer, developer, etc. If you don't have one or more roles available, you will have to hire them externally. Headless projects are often hefty in terms of impact in hours, so make ample budget available.

3. Customizations

Another factor that can drive up the price of a headless CMS implementation is the need for modifications. For the front-end, a headless CMS gives you an enormous amount of freedom, but because you can't just access the source code of the CMS (as there is a company behind it), you can't just make a few modifications to the system. In many cases you don't want to do this, but if you have specific wishes on how a solution should work, it is wise to research this well.

4. Apps

This section is not relevant to everyone but we have seen it come along a number of times over the years: an app. If a company has its own app, it is often developed as a 'monolith' alongside the existing communication (portal, website, etc). When a company chases the 'omni-channel content' philosophy, this app must also 'suddenly' be included in the headless journey. So it is better to think of this in advance than halfway through or at the end of the journey.

5. Integrations

A website or app rarely stands alone, especially within a headless CMS implementation. Often (raw) data must 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 have to purchase to create links.

See beforehand if a headless CMS can integrate using a GraphQL, REST API, webhooks and/or Zapier or Mulesoft. The more linkable a CMS is, the less valuable time needs to be spent on expensive integrations.

6. Hosting / safett / upgrades

The final component concerns hosting, security and ongoing development. If a headless CMS is also a "hosted CMS," hosting, security and upgrades are often handled centrally. These costs are then factored into the license price. In some cases, you have to pay extra for use and hosting if you exceed the fair use policy.

If you choose a "self hosted" headless CMS then you will have to take care of these things yourself. This can have quite an impact on your budget. Especially security is a component that requires attention, so analyze in advance who is responsible for this component.

Conclusion

Over the years, we have watched and participated in over 1,000 CMS selections and implementations. And yes, we will be quick to recommend Plate, we have to be that honest. Yet we've learned over the years not to onboard just any client and trajectory on the Plate platform. We want clients to consciously choose Plate because they think carefully about what they have and don't have. If another CMS turns out to be a better fit, we don't really think that's a problem. The market is big enough and we know where we (want to) be strong.