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:

A development environment where the latest changes sit ready to be reviewed and tested by the development team
A staging environment where recent changes are ‘staged’ ready to be signed off
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.

Signup to our Newsletter

Sign up to our newsletter