In the past 15 years, I’ve written five Content Management Systems and built a leading CMS software company. Now let me tell you why you shouldn’t write your own CMS.
A market that didn’t exist
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.
Productizing a 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.
Surprise: People are still writing their own custom CMSs!
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.
Headless architecture makes custom CMS obsolete
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.
Reason #1: Standard CMS limits my creativity
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!
Reason #2: Standard CMS interfaces are too complex
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 creepas 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.
Reason #3: Standard CMS is too expensive
“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.
Reason #4: Standard CMS is not secure
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.
Reason #5: Standard CMS doesn’t fit my architecture
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.
Reason #6: We still have plenty of customers on our agency’s CMS
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.
… and two reasons when a custom CMS is justifiable
To be fair, there are situations when writing your own CMS still makes sense or it’s the only way to go:
- Content management is your core business: If you’re a company like Medium, you may want to have absolute control of content management. If you’re a big media house with dozens of publications and need a completely customized workflow, you may want to write your own CMS (or at least create a custom editorial UI). However, there are VERY few companies in the world who fit this category and can justify the ongoing investment.
- Unique security or compliance requirements: Again, there are a few organizations that need to adhere to specific rules when it comes to content storage, security, software architecture or infrastructure, and these rules do not allow them to use a standard CMS.
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.
Avoid writing your own CMS, unless there’s a clear business case
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.