I Know How To Build A CMS…Which Is Why I Never Would

Growtika - a-computer-with-a-keyboard-and-mouse

I have been a web developer for almost fourteen years. In that time I have built websites and web applications from scratch, and using a wide variety of frameworks and CMS systems. I have worked on frameworks such as Laravel and Next JS, with CMS systems such as WordPress, Statamic, and Magento, and with four programming languages; PHP, JavaScript, TypeScript and Python.

The more time you spend working in web and software development, the more you have an appreciaition for not overcomplicating work, and certainly for not reinventing the wheel. I could build a CMS (Content Management System) as I am sure many experienced web developers probably could, but that doesn’t mean I/we should. Doing so means you often risk “reinventing the wheel” unless you are building a CMS for a very specific use case that cannot be done with another system. For the overwhelming majority of websites that is not the case and there would be a CMS system that can fit virtually any use case with adequate and appropriate customisation through custom modules/plugins or themes.

One thing that is important to note when building a web application is that just building it is often the minority of the work that goes into it. A successful website will need to be maintained, updated and added to over time. And with changes in web technologies, the code will need to be updated also. If you build a custom CMS for your website you are essentially doubling your work. The building of both the website and CMS is only the initial work. After that you will need to not only maintain the website source code and its content, but also the source code of the custom CMS system. Choosing an out-of-the-box CMS solution, for even an experienced developer, is often the far more efficient, secure and sustainable solution. A custom solution would mean being indefinitely responsible for security updates, refactoring code for browser and technology changes, managing technical debt, debugging obscure bugs, and finding yourself thinking of new features to build because you can and to make building the CMS feel worth it. Coding is only one of the parts that go into building a website. The discovery stage, gathering requirements from clients and/or stakeholders, is often done before a single line of code is written. Then the architecture is planned, including choosing the CMS system which will be used, if any. Even when building a website for a client, as a first choice I would always choose an off-the-shelf CMS and/or framework rather than building it myself unless absolutely necessary.

Of course there are some cases where building a CMS makes perfect sense. One such example is if you were looking to release it to the community as a product (either open source or proprietary) for other web developers and content managers to use. But even in this case, the CMS market is incredibly saturated and unfortunately if this is your goal the chances of your CMS standing out and being picked up is very slim. That’s not to say it’s impossible but the odds are against you and your CMS would need to really have a unique USP to be picked up when there are so many well stablished platforms out there with huge communities of developers and users behind them. If I had the choice between building a new website with an incredibly well coded and well structured CMS system or framework that was released only a couple of months ago and had a single digit number of downloads, or one with a huge community and long history behind it like WordPress, Drupal, Laravel, Symfony or Django – I would choose one of the latter. And that would not be personal to the developer(s) who created the new system or any reflection on their abilities but with CMS systems and frameworks, age and scale of adoption is a signal of stability – the codebase is unlikely to be abandoned soon, updates will be frequent as more developers will be contributing to it, and it will have a large community of developers already using the system to build and can provide support in edge cases.

When I decided to start blogging again, I had to decide what platform I would use and how I would get started. As mentioned, as a developer I could have built a CMS system from scratch but I chose a standard WordPress.com blog. Not even a self-hosted WordPress CMS instance. A regular, normie WordPress.com blog. I did not need to write a single line of code to get started and that was a deliberate choice. Not because I don’t know how to – I clearly do. But I just wanted my blog to be a blog, not another system for me to maintain (and without being paid to). I love being creative and building stuff which is why I became a developer all those years ago. And I actually love coding, but outside of my working day the last thing I would want to do is be maintaining a CMS system for my blog. I know it would become a project in itself if I customised everything. I would have ended up finding new features to build, making code changes for security updates, and debugging inevitable obscure bugs. If I am to write code outside of my professional work, it will be a whimsical Codepen project or another fun project (such as my BiblePHP package or similar).

As developers we sometimes make a habit of turning our hobbies into software projects. Ten years ago I probably would have built my own CMS for my blog. I was less experienced in my field and it would have been a fun technical challenge and a good learning exercise for me. Today, I would rather spend that same time on a weekend or evening writing a blog post, reading a book, spending more quality time with my son and wife, enjoying a beer in the pub, watching football, or running a Call of Cthulhu game.

Leave a Reply

Discover more from Chris in Tweed

Subscribe now to keep reading and get access to the full archive.

Continue reading