Choosing your headless CMS

Things you might wish to consider

7 mins

We’re currently in the process of choosing a new Content Management System for a client, whose new site we are building in the new year. Perhaps surprisingly, their current site (which we’ve been supporting for the last 7 months) was built in WordPress, an architectural decision, I suppose, that was taken when they were a much smaller brand.

Fast forward to 2020, and this client is operating 50 sites in 6 territories globally, and their site is in 4 different languages. WordPress has become a pain.

Why a headless CMS?

Actually – maybe we should start with the what:
A headless CMS is what’s known as a decoupled application… that means that the backend and the frontend are 2 separate applications that talk to each other via an API. (As opposed to just one monolith application).

Who cares, right? Well:

  • Traditional CMSs dictated the programming language with which the templates in the frontend had to be built. So, WordPress had to be in PHP, Umbraco in .NET, Magnolia in JAVA and so on. By decoupling the application, the development can build the front end in whatever they want. And that means they can just build in what they’re best at. And that’s a good thing.
  • Decoupled applications provide more flexibility when integrating with other systems and are easier to scale.
  • It’s easier to swap out a CMS for another one (for example as a company grows or requirements change)
  • If there is any chance that content from the site will need to appear in more than one application, for example a website and a phone app, then a headless CMS makes this possible.

Criteria to help

Many clients are surprised when, at the beginning of a project, we don’t recommend a CMS. Naturally there are some in which we have more experience, but that in isolation isn’t a good enough reason to pick one over another. We try to remain agnostic until we understand the requirements of the project: different platforms are better for different clients. Never should it be assumed that one size fits all.

The headless CMS arena has blossomed somewhat in the last year or so, with some excellent new players to the market. Because of this, we delved into a LOT of possibilities and here is the list of a criteria we came up with for helping to make the right choice.

 

Is it self-hosting?

This may or may not be what you want… but not that many vendors offer both options. You maybe have a preference that’s based on cost or scalability but either way you should check.

 

Was it originally built to be headless?

That’s not to say traditional CMSs with an API add-on aren’t good. But a CMS built to be headless from the ground up will normally suggest a cleaner code base. And that translates into better updates, an easier site build and happier development team.

 

Quality of API

Remember what the API lacks you will have to build. Can you build custom parts of the admin interface? How many types of API are there? Is it just REST, or is there GraphQL too? This might not mean much to you, but I promise – it means a hell of a lot to your dev team. The better the API the more they can build to your requirements which out making a wincing face.

 

Cost

This might seem obvious, but consideration needs to be given to not only the immediate requirements, but what the requirement might be over a period of 5 years or so. What happens if the site or app you build suddenly shoots up in traffic, or you need double the amount of a content types? Will your choice of CMS allow some flex? You often see vendors offering a vague sounding ‘enterprise tier’ with no details of price. In our experience that price is approximately 10 times that of the most expensive advertised tier. You have been warned, not all vendors are prepared to barter.

 

Documentation

Well written documentation will save you a lot of time, and the quality varies massively between vendor. Do the due diligence!

 

Active developer community

All WordPress developers have jumped through some hoops to get the job done. Whilst some of those hoops are just downright bizarre, you can at least almost guarantee you’re not the only one to stumble across one – one glance on StackOverflow and that’s abundantly clear. Bear in mind that on lesser known or lesser used solutions, you might be left to figure things out on your own. Whether that matters depends on the confidence of your dev team.

 

Affordable enterprise support

Whether or not this is necessary will depend on the client’s requirements but sometimes it’s useful to have the developers who built the system on a dedicated Slack channel. I’m also including uptime SLA in this too. What happens if it’s hosted by the vendor and it goes down. Do they guarantee 99.9% uptime? Or will you have to build in your own redundancy?

 

Does it fit your data design?

Please, for the love of God, start with the data structure that the site needs! And then choose a CMS that can handle it. This might include:

  • Modular content
  • Internationalisation
  • Different regions
  • Categories and taxonomy
  • And a plethora of nomenclature and objects that you might need. Talk to the product’s stakeholders, and design this around what they need. And only then, should you choose the CMS which can achieve that structure.

 

Can you automate tasks with scripts?

How easy is it to fire up new instances of the site?Can you simply copy a live site to develop on, or duplicate areas or the site to develop on? Can you script the data structure separately to the actual content itself? Anything that can be done to prevent monotonous task repetition is a very good thing, especially when your dev team is up against a deadline.

 

Good for different environments

Any site that’s being developed or supported should have at least 3 environments:

  1. A development environment where the latest changes sit ready to be reviewed and tested by the development team
  2. A staging environment where recent changes are ‘staged’ ready to be signed off
  3. A live environment – which is the version accessible to the public.

If it’s easy to transfer data and configurations between these environments, then your team will have a lot less grief and deployments will be much easier. WordPress traditionally has been a pain (you essentially have to host 3 versions of the website). Whilst plugins exist to make it a little less painful (for example DB Migrate Pro) their security credentials are horrendous and it’s far too easy to overwrite important data.

WP Engine and Flywheel (companies that specialise in WP hosting) try and do a better job in their respective admin interfaces – and in most part they do. But ultimately, they work with painful and flaky migrations… because WP is painful, and flaky.

 

Quality of administration user interface

If the user interface is good, then tasks will be intuitive and easier to complete. It’s amazing how many interfaces are ill conceived and confusing, especially that there are so many good admin ‘themes’ you can buy off the shelf. We’ve analysed a few recently and many we just aren’t prepared to show clients. Interestingly this is a point where WordPress is actually not that bad!

 

Ability to customise the admin interface

A headless CMS will have a read API, but if it’s got a write API too then you can build your own interface for a custom CMS yourself. Some CMS also allow you to customise aspects of their own interface too which is useful.

 

Low risk in longevity

The importance of this shouldn’t be underestimated. With any luck the site that you build and support will last about 5 years. So with that in mind – what’s happens if the CMS you choose doesn’t last that long? If it’s self-hosted it’s less of an issue, but you won’t be getting any improvements or updates in that time. If it’s a CMS as a service – then you’ll need to think of another solution. Are you confident in your vendor’s ability to stick around for a while?

 

Is it in a language we’re okay with?

Every developer and tech team will have framework, language and platform preferences that’s perfectly natural. Sometimes it’s the main reason why a CMS is chosen, and it’s not a bad thing to be using a language that they like or they’re comfortable using.

 

How easy is it to create draft previews of content?

This isn’t necessarily out of the box functionality when you’re not using a template based traditional CMS, although many have a preview API.

 

Quality of known client list

We’d like to think it wouldn’t massively affect the decision, but if you’re an agency and you’re proposing a particular choice of CMS to a client, then a particular brand might have some gravitas to help your cause.

In conclusion

There is no way that each of the above criteria will have equal importance, so you’ll need to weight each of these accordingly. And, as it happens, it’s unlikely that, from project to project, you’d score each criterion consistently, so we’d advise doing this process each time.

The method of scoring and weighting is completely up to you, of course. And might be the subject of another blog post. But we thought it might be worth noting down some of the things we think about. Choosing a CMS isn’t an insignificant amount of work, and the decision you’re stuck with for a while. So, in our mind, it’s important to put some time and love into the process and make the best decision possible.

Don’t make the choice on a whim! And if you’re looking for help making that choice, we’d love to find out how we can help. Get in touch with us today.

Related Insight

Sign up to our newsletter?


Trust us, it won't be that often, and only when we have something interesting to say.

We'll never share your email with anyone else. By clicking 'subscribe' you agree to Spork Digital Ltd storing and using the information above as set out in their Privacy Policy.