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.
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:
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.
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.
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?
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
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.
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.