Image source: https://pixabay.com/en/girl-kids-africa-animals-asia-1822525/
“Writing your own CMS is like keeping your own elephant — for most people, it’s just easier to visit a ZOO.”
Back in 2000, I was studying at university and working as an intranet developer, posting content on an intranet written in static HTML. It was my first “programming” job and I really enjoyed it — for a few weeks.
Then it became apparent how repetitive and manual the work was. So I began writing an application in classic ASP that would allow users to manage content themselves. I had no idea that something called a Content Management System even existed, so I unknowingly invented my own.
At that time, there were very few productized CMS systems for purchase, often costing hundreds of thousands of dollars.
So it’s no surprise, considering the size and inaccessibility of the software category that I wasn’t alone in trying to minimize frustrations and maximize efficiency by creating my own CMS.
By 2004 almost every web agency was building its own CMS, often customizing it for each client. This resulted in dozens of modifications that were a nightmare to manage.
“That doesn’t make any sense,” I thought to myself. I’d already written a few single-purpose CMS systems and was bored again. “What if I wrote a CMS that could be used for any website?”
So, I started my own company, Kentico Software, with a very simple vision: to build one CMS that any developer in the world could use to create any website.
13 years later, I’m still shocked by the number of people who choose to build their own CMS.
There is now a plethora of mature CMS products out there, for all kinds of projects, available in all sorts of flavors: from free open source to enterprise-level commercial products, from best-of-breed products to all-in-one suites.
So why would anybody write their own?
The answer is actually pretty simple: They do it out of frustration.
And I get it. Traditional web-oriented CMS systems can be fraught with flaws and limitations. But the truth is: these frustrations are no longer valid.
I know; it sounds hypocritical… writing my own CMS worked for me, so why not for them?
Let me explain.
In the past 15 years, the CMS market and technology have transformed to keep pace with the changes to the digital landscape and customer’s multi-device expectations.
And now the next generation of CMS technology — the cloud-first headless CMS — is getting ready to revolutionize the Content Management industry.
Unlike traditional CMS systems, headless CMS products only focus on content management and make the content available through API to any application.
As they lack the “head” that would normally dictate how the content should be displayed, a headless CMS leaves this design element completely up to the developer.
Cloud-first headless CMS removes many limits of traditional CMS solutions
So this is why it’s not a good idea for developers to write their own custom CMS — unless, that is; they want to become a CMS vendor too.
But that’s easy for me to say. I’m not the one faced with multiple frustrations and finding many reasons why a custom CMS would be the way to go.
So let’s take the main reasons in turn and see why they are obsolete.
When you talk to front-end developers, their #1 complaint about CMS is that it messes up their HTML code and makes them look for workarounds.
But that’s over: headless CMS gives you absolute freedom and it has a zero footprint in the resulting HTML code. All you need to do is call its REST API using your favorite programming language to retrieve the content from the repository.
Then, it’s completely up to you as to how you display the content!
Many traditional CMS systems have grown substantially over the past ten years. Although all of them started with the idea of providing a great content management solution, most of them failed to avoid a feature creep as they expanded into areas like e-commerce, marketing automation, booking systems, e-mail marketing, etc.
While it may be handy to have everything in one place for some users, it’s challenging for new users to learn the CMS. If all they want to do is manage content, too many options impact their productivity
The new headless CMS products come from a different perspective: they realize they are just one piece of the puzzle of microservices and they focus on providing a much more streamlined user interface focused just on content.
At the same time, they usually provide a Content Management API that allows you to create your own editing interface on top of their content repository.
This may be handy when you want to create a more streamlined UI or integrate content editing capabilities within your own application, instead of redirecting your users to another interface.
“We didn’t want to pay $X for a commercial CMS, so we decided to write our own.” That’s what you may hear from some developers.
Unless you need something much simpler than a real CMS (such as managing a list of news), there’s no way you save money with a custom CMS in the long run.
Today, you can choose from a whole host of free open source CMS or you can go with a cloud-first headless CMS that offers consumption-based pricing that will always beat the cost of developing and running your own CMS.
For many organizations, CMS security is a nightmare. So some developers think, “If we write our own CMS, we will make it more complicated for hackers to find a flaw.”
That’s what we call security by obscurity.
While it’s true that hackers may leverage a known security issue, a widely used CMS is usually vigorously tested. In fact, the main source of security issues is companies failing to apply the latest hotfixes to the various plug-ins employed.
With a cloud-first headless CMS, you’re always on the latest version. The CMS is hosted directly by the vendor who knows the code as well as the infrastructure and can devote appropriate attention to security.
This used to be a valid reason in certain scenarios. Most traditional CMS solutions were expected to be used as the central platform on which to build, meaning that your application code was tightly coupled with the CMS, as illustrated in the picture earlier in the article.
You were limited by the CMS platform, programming language, upgrade cycles, scalability, and security.
It’s no wonder so many software architects wouldn’t take that path! Instead, they either created a proxy layer between the CMS and their application or — surprise! — they wrote their own CMS.
Fortunately, the headless CMS architecture allows you to easily access content using an API and write your application just the way you like it.
Many digital agencies continue to run their own CMS for their clients.
Some of them even use it intentionally to lock their clients in so that they cannot easily move to a different agency.
In general, there’s absolutely zero advantage in an agency having its own CMS. Unless they aspire to becoming a CMS vendor, they should run away from their own CMS as fast as they can.
Fortunately, most agencies I talk to realize it’s not the way to go and that they can’t stay competitive in the market with their proprietary CMS.
However, they are afraid of making a leap of faith and moving their customers to a standard CMS.
In some cases, it’s also an emotional or political decision. The CMS was written by the agency founder many years ago or it’s the baby of their best developer who, after all, is the only person who knows how the CMS works.
My advice: Make that bold step before your agency becomes obsolete!
Choose a modern CMS for your customers and highlight the many benefits it affords them.
And give your developers a new toy to play with! Hint: most developers fall in love with a headless CMS very quickly.
To be fair, there are situations when writing your own CMS still makes sense or it’s the only way to go:
Even if you fit some of these scenarios, you should keep in mind that every hour you spend building a custom CMS is an hour you could be spending on creating your competitive advantage instead of reinventing the wheel.
People ALWAYS underestimate the amount of effort that goes into building a true CMS.
Your first thought may be “What’s so complicated about a CMS? I just use a document database and build some editing interface on top of that.”
Yes, that’s an easy start, but it’s not a true CMS. Once you start adding layers, such as content modeling, versioning, language variants, workflow, permissions, content delivery, search, etc. you find yourself developing and managing a fairly complex solution.
By now, it should be clear that writing your own CMS sucks. It’s a great programming exercise, but it’s not your core business — unless you’re a CMS vendor.
Full disclosure: I’m the founder of Kentico Software, a leading CMS vendor that behind Kentico Cloud, the cloud-first headless CMS. Although I wrote this article with the best intentions, my view may be biased.
If you enjoyed this article, please clap it, share it or post your comment below. I promise to answer all questions.