Choosing your headless CMS

We’re currently in the process of choosing a new Content Management System for a client, whose new site we’re due to build in the new year. Their current site (which we’ve been supporting for the last 7 months) was built in WordPress, an architectural decision that was taken, I suppose, 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.

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, developers can build the front end in whatever they want and that means they can build in what they’re best at. That’s a good thing.
• Decoupled applications provide more flexibility when it comes to integrating with other systems and are easier to scale.
• It makes swapping out one CMS for another easier (for example as a company grows or requirements change).
• If content from the site needs to appear in more than one application, for example a website and a phone app, then a headless CMS makes this possible.

Clients are often surprised when we don’t recommend a CMS right at the beginning of a project. 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 may 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 normally suggests a cleaner code base. 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 without 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 traffic on the site or app you build suddenly shoots up, 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 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. 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.

When it’s easy to transfer data and configurations between these environments, your team has grief and deployments are 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, tasks will be intuitive and easier to complete. It’s amazing how many interfaces are ill conceived and confusing, especially when 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 as well 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 you build and support will last about 5 years. 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 is one of the key reasons 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.

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.