Do you really need a Content Management System?

At Creator, we build lots of sites for clients, where within the specification is a requirement for a CMS. A CMS is normally a user-friendly back-end to the site where users of all levels can edit/add and administer content updates. Whether that’s adding a new blog post, adding a new employee to your ‘Team’ page, or adding a new product to your website.

We’re advocates of WordPress, and if you’ve ever used it – Congratulations, you’ve used the most popular CMS in the world.

We use WordPress in both ‘Full Vanilla’ builds, which are 100% WordPress on the front-end, and ‘Headless’ where we use WordPress’ API to feed content on a front-end built in something like ReactJS or VueJS. We normally opt for WordPress for a couple of reasons:

The first is cost.

WordPress and Advanced Custom Fields will give you something which is arguably similar to a platform like Contentful, or DatoCMS. WordPress is free, DatoCMS and Contentful aren’t. The base level of each is a low monthly cost, but subsequent levels can quickly rise your small monthly payment.

The second is familiarity.

WordPress is some awesomely popular, that when we engage with a client, it’s extremely rare that there’s not somebody in the organisation who’s had previous experience administering updates to a WordPress site. This is great for us, as we know when we hand the site over, there’s going to be someone on the client side who understands how to work with the backend, and will only require a small amount of training, on perhaps, very specific, bespoke functionality we’ve added.

When we approach a build, we first look at the specification and after we’ve ascertained that we can meet the spec using one of these two methods, we engage with the client and commence discovery and subsequently the design and build of the site. The one thing I’ve never questioned is the need for a CMS, but in recent builds, where clients have retained our services for updates, maintenance and other aspects of design work – we often manage the CMS for them. This is fine, we don’t mind doing this at all, we love our clients and want to engage with them to help them build their vision.

That being said, in some recent builds we’ve completed, there has been a requirement for a CMS which has quickly been made redundant after project launch, as we’re engaged to administer website updates to the site – something which in some cases, can be quicker to code than to use the CMS to update.

We’ve also just finished building a site which has a CMS where most of the content is programatically created from an API feed. The front-end is populates the content on the site by using some logic to determine the written content that should be displayed on the page, from a series of text variants.

There’s only very few pages on the site where the content is within a CMS and requires a webmaster (yes, hello 1995) to update. I’ve also noted that nobody internally has ever logged into the CMS, and all updates to these static pages have been done by our good-selves.

We often think of a CMS as a non-negotiable, if a client requires it, we’ll turn to an appropriate solution in order to give them the functionality they desire. But given recent experience, I feel in future project scoping, we’ll be discussing the need for no CMS at all. It’ll save time on the build if we’re writing something static that we don’t need to do any CMS plumbing on, which may free up some budget within the project for us to work on extended functionality. It also means we’re not hitting the client with any maintenance of the CMS (I’m looking at you, WordPress) or legacy costs on headless providers like DatoCMS.

Static may just be, the future.

You heard it here first.