5 hidden costs of using a traditional CMS

Summary

There are a number of different CMS solutions out there, ones that are open source, ones that are built for blogging, ones that are built for customisability, ones that are built for media publishing, so on and so forth.

One can very well pick any traditional CMS solution and make it work for media publishing, but the price you pay may be far more than you expect.

Publishers sometimes pick traditional, coupled CMS solutions because they are cheaper as well as easier to set up and get going. Or so they think.

Let’s delve into some of the costs under the hood that publishers don’t realise that they incur while using traditional CMS solutions.

Infrastructure

Photo by panumas nikhomkhai from Pexels

A traditional self-hosted CMS instance requires, as the name suggests, hosting - You have to host all your content in addition to the domain name server on services such as Amazon AWS, Google Cloud, etc. which will cost upwards of $1000/month. One must also invest in Content Delivery Networks, like Cloudflare, Akamai etc. which will cost you another $200/month, as well as image optimisation, which all help with speeding up distribution and ensuring stability when content goes viral.

This can be a costly affair, as high quality services can be prohibitively expensive for individual publishers trying to strike a deal with the service.

Effectively publishers may be forced to choose less reliable services that lead to site downtime ie, your site being non-functional and you being unable to reach or deliver content to your audience.

Plugins

Plugins are magic! They enable a traditional CMS solution to do things that it was not built to do without too much of a hassle, right?

Well, the downside to using plugins is that they drastically affect the performance of a website in a detrimental fashion.

A publisher also has no control over the code in a plugin - They have no say in the versioning, features, support, etc of any third party plugin.

This jeopardises the publication whenever the developer of that plugin decides to either stop supporting it, updates it to a newer version or even changes the way it functions because their website now relies heavily on these plugins to function.

Software Versions

Photo by Markus Spiske on Unsplash

Most traditional CMS solutions or open source CMS software have teams who work on the software, often releasing it in versions. These can be volunteers or even paid teams that work on everything from features to bugs, bunching them all up together to release them to the world as different versions. These versions though, often are not compatible with the previous versions of the software, the front-end code, the plugins etc. leading to you to a situation where you have to rework your website to get it back into a functional state. Hence publishers are forced to invest heavily in tech teams every time they want to update their website’s software versions. This also leads to a lot of publishers choosing not to update their version due to the expense and hassle, leaving them behind the curve when it comes to the technology.

Security

Data security within the website’s platform is a key issue, that often comes back to haunt publishers who pick CMS solutions that may not be built with enterprise-grade security. Oftentimes, traditional CMS solutions have a number of security issues due to the fact that they are not built with the aforementioned enterprise-level security in mind. Their large-scale use allows for malicious operators to find ways to infiltrate them and then distribute these methods online for others to use. Software is also bunched up into security patch updates which leaves websites unsafe in the interim. As we’ve discussed earlier, sometimes publishers just cannot afford to invest heavily in the development cost of upgrading their websites every time a patch comes out, or risk breaking their website while doing so, leaving their websites and platforms vulnerable.

Performance

Photo by Guillaume Jaillet on Unsplash

Using a coupled CMS, which is not built specifically for media publishing, can detrimentally affect the performance of a website. Every plugin, every additional script that is unwittingly added to customise a website, slows it down. The bounce rates on websites with poor performance tends to skyrocket as audiences do not want to wait for their content to load and when welcomed with blank screens, they decide that they’d rather consume their content elsewhere. A poorly performing website that takes more than 3 seconds to load can affect your traffic by driving people away and even cause you to be penalised on the SEO front. A case study conducted by the Financial Times showed a 5-7% drop in engagement for every additional second taken for a site to load.

Correlation between drop in performance and engagementGadi Lahav, Head of Product, Financial Times - How A North Star Helps Develop Better Products

Some publishers go the extra mile to invest in building their own CMS solution based on whatever is out there, but find it difficult to hire good tech talent due to the dead-end that engineers see in their tech careers as a part of a publisher. This leads to publishers having to pay more for less quality and diluting the mission of the publication, leaving them in limbo as to whether they are a tech company or a publishing firm.

Summary

Publishers tend to pick a traditional CMS solution as opposed to one that is built specifically for the purpose because they see that the initial setup seems considerably cheaper. However in the long run, as one can see, the price one pays can be rather damaging.

Conclusion

Picking a headless CMS that is built specifically for media publishing can benefit publishers in many ways:

Economics of scale allow larger tech companies to strike a better deal with infrastructure services, the benefits of which can be passed onto publishers.

Integration of all the required features into the CMS itself by virtue of it being built for media publishing ensures that performance does not take a hit.

API-based integration ensures that headless CMS solutions are more versatile to whatever requirements that a publisher might have

Seamless updates of software without versioning in addition to the decoupled nature of headless CMS solutions ensure stable no-downtime during any upgrade required.

Enterprise-grade security integrated into enterprise-grade CMS solutions ensure the safety of the data and the platform.

A headless CMS built for media publishing ensures that any front end can be built using the APIs from the CMS ensuring maximum performance

Publishers have complete control over the roadmap and details of their website’s software as they have control over the software either directly or through their tech partners.

If you’d like to find out more about how you can leverage an enterprise-level headless CMS solution for your publication, you can reach us at sales@quintype.com