Maybe, Just Maybe, Your Website Doesn’t Need to Run on a CMS

When Matt Mullenweg locked horns with WP Engine, hijacked popular WordPress plugins, and stressed out the open source community last year, I saw a lot of people asking about WordPress alternatives — which is no minor thing given WordPress’ dominance of the CMS market.

The responses were wide-ranging. People recommended open-ended CMSes like Craft and Statamic, blogging-centric tools like Ghost, visual site builders like Squarespace and Webflow, and static site generators like Eleventy and Hugo. Heck, I even shared my own list of WordPress alternatives. All of which go to show the incredible diversity in today’s CMS market.

But there’s one option that I never saw mentioned: not using any CMS at all.

These days, building a website on a CMS is basically a given, for several reasons:

• CMSes are great for managing content that follows a consistent structure, like blog posts. While you could run a blog as a static website where each post is its own HTML file, that will only grow exponentially more cumbersome as more posts are published. (I know this all too well from Opus’ earliest incarnations.)
• CMSes are great for websites managed by a team. Individual users can have their own account and access privileges while the admin area ensures that anything published on the website is consistent, regardless of who worked on it or their level of technical expertise.
• If you’re building a client-managed website, then a CMS is almost mandatory. No developer in their right mind wants their client mucking about with raw HTML. Heck, even if you’re a skilled developer, sometimes it’s nice to use a CMS like Squarespace so you don’t have to muck about with raw HTML.

But for all of their many benefits, CMSes — even the best and most modern ones — come with no small amount of overhead.

• You need to keep the CMS software up-to-date, as well as any installed third-party plugins. And if you’re not using a managed hosting service, then you also need maintain the server software (e.g., Apache, PHP, MySQL) on which the CMS runs. Failing to do so will eventually result in performance and security issues.
• CMSes can require more expensive hosting solutions because of the resources they use. This extra cost might not be exorbitant if the website in question is a small blog or personal website, but it can quickly increase. On the other hand, hosted CMSes like Squarespace often charge a monthly/annual fee. Finally, many CMSes do offer free versions but more and more developers are beginning to charge for premium features, upgrades, long-term support, and plugins.
• Most modern CMSes use a templating system to render content on the front-end. This isn’t a bad thing; visual consistency is good for structured content like blog posts. But it’s easy to get stuck designing things a certain way. Thus, when you do need some variety, that can involve rewriting and rebuilding your templates to accommodate new layouts. Depending on your CMS and how you’ve structured your templates, that can be a non-trivial task.
• Using even a really flexible CMS can mean thinking about content management its way. If you want to do things differently, you might need to find a third-party plugin that provides the desired functionality and/or write some custom code. (If you’ve done any WordPress development, think of all of the times you’ve hacked your theme’s functions.php file just so you could do something really simple.)
• No CMS is immune to bloated, overly convoluted front-end code. It’s possible to build a lightweight WordPress theme, for example, but if you use a third-party theme or page builder, don’t be surprised if your website gets bogged down with numerous assets — all of which can impact performance. (I once inherited a WordPress website that, as a result of using a popular page builder, loaded a combined total of 60+ CSS and JS files on every single page.)

For many websites, the above issues might be perfectly acceptable trade-offs for the advantages and convenience that a CMS offers. But not, I think, for all websites. Perhaps not even for yours.

This was impressed upon me last year when I set about preparing a client’s website for a new hosting environment and further confirmed when I recently redesigned my church’s website.

The previous version of my church’s website was built on Squarespace, which made sense when we launched it. But Squarespace offers — and charges for — a lot of functionality that we no longer needed. Furthermore, if you’ve ever developed on Squarespace, then you know they’re not exactly the lightest or simplest of websites.

When I began the redesign, I defaulted to weighing my CMS options. In a moment of geekiness, I thought about using the new website as an excuse to play with some CMSes that I’ve always wanted to try. I soon realized, however, that any CMS would likely be overkill given the following factors:

• The church has a very small staff, so it would likely fall on me to make any updates to the website regardless of whether it ran on a CMS or not.
• After evaluating the previous website’s content, we realized that much of it was old and no longer necessary or relevant. Thus, the new website simply wouldn’t have a lot of content to be managed in the first place.
• Like many churches, we use Planning Center to manage our events, church directory, etc. Planning Center offers widgets (e.g., forms, calendars) that can be embedded in webpages and pull info from our Planning Center account, which removes the need to build out that functionality in a CMS.
• Our church is relatively small and casual, with a diverse and close-knit community, something that our pastor really wanted the new website to emphasize. As such, using a CMS to enforce conformity just seemed wrong given our ethos.

Of course, building a completely static, CMS-less website comes with its own trade-offs, which should be considered before going that route. For example:

• Since you’re not using any sort of page builder, you’ll need to develop your own design framework or use something like Tailwind. (I opted for the former because I’m a nerd.)
• You’ll need to handle all of the image cropping and resizing, and figure out how to best store and organize the website’s assets.
• Depending on your hosting environment, you might need to put on your sysadmin hat and learn about maintaining LAMP stacks and other server-related issues.
• If you ever step aside from the project, you’ll need to hand your code over to another developer to maintain — which can make for a difficult transition.

Truth be told, though, I enjoy thinking through such things.

• I enjoy rolling up my sleeves and digging into the website’s HTML, CSS, and JS.
• I enjoy having complete control over every aspect of the website and not having a CMS or page builder do anything for me (i.e., get in my way).
• I enjoy thinking through the best ways to organize the website’s code and assets and ensure that they’re easy to understand and maintain (for myself or anyone else).
• I enjoy building out the website’s CSS from scratch, exploring different JavaScript techniques to improve its accessibility, and writing custom PHP to make the website run more smoothly.
• And I enjoy knowing that the website, being entirely static, will be highly performant and need minimal (i.e., cheaper) hosting resources.

Needless to say, I enjoyed the challenge of rebuilding a website using plain ol’ HTML, CSS, and JS, and I’m very pleased with how the new website turned out even as I continue to refine its design.

Make no mistake: CMSes are great tools and I love experimenting with them. As a UI/UX developer, I’m inspired by how different CMSes tackle the very real problems of managing website content, users, assets, etc. But I fear that us web developers have come to rely on CMSes too much, assuming that every website needs to run on one — an assumption that does us a disservice.

If you’re new to web development, building static websites by hand is the best way to learn and understand HTML, CSS, and JS. If, on the other hand, you’re an experienced developer with lots of websites under your belt, then I challenge you to take a step back and consider not using a CMS sometime. As inefficient and counterintuitive as that might seem, you might just find it refreshing to build a website using the web’s most basic building blocks, and even learn something new.

To be clear, I would never say you’re not a real web developer if you can’t build a website without a CMS. I will say, however, that forgoing the CMS — on the right project, of course — is absolutely a valid option, and one that more web developers should consider more often.