I recently came upon this article written by a CMS developer who was amazed that a potential client chose a custom CMS over their recommended solution. I see these articles on occasion, and they always aggravate me to a certain extent.
The reason is because custom CMSs continue to make a ton of sense for enterprise clients—more so now than ever before.
The real shock here is that more developers don’t see custom CMS solutions as a viable option. They are stuck in a bubble overrun with off-the-shelf solutions. Oftentimes, they can’t even tell that the professed “benefits” of off-the-shelf software are the same detriments that lead to customers eventually wish they had traveled down the custom development path from the beginning.
The writer of the article posed some interesting questions and arguments which we’d like to answer, starting with this:
Have you ever built a CMS before? Have you ever used a custom CMS? The answer to both is no. Because if it was yes, you would not even consider doing it.
To the contrary, we’ve been building custom CMS platforms for over 15 years. When we began, the custom pathway was pretty much the only option for website developers. There weren’t any off-the-shelf solutions such as WordPress, Drupal, or Joomla. Those platforms developed over time and did indeed make life a lot easier. However, one could argue that they also ushered in an era of “sameness” on the Internet. An era where a true “web developer” can’t be distinguished from a “themer” by most business owners.
But I digress. Ultimately, in this article, I want to reply directly to the original author’s points regarding why off-the-shelf solutions are superior to building yourself. He posits the following arguments with the idea that the available CMS solutions offer more value because they can handle these issues better than a custom solution.
“The ability to add customized workflows that can change over time, without recoding anything”
In reality, this is completely the opposite. CMS platforms taken off the shelf often require the end user to adjust their workflow to match the software.
For example, WordPress is still based on “posts” and “pages.” They have tried to make their taxonomy a bit more flexible with custom data definitions, but they still call those “custom post types,” a tribute to their original architecture.
The fact is, more often than not, clients must adjust their internal workflows to match the platform that they are on, often adding steps to make the software function the way they require.
Case in point: We built a CMS that allows a leading digital newsroom to create original video content, starting at the research phase and allowing full control through writing, editing, and ultimately distributing to many different devices and publication methods.
This all happens in a live, interactive environment across multiple geographical locations. There was no off-the-shelf solution that would have allowed them to mold the software precisely to their workflows. Their speed of production with their custom CMS enabled them to be an interrupter in their industry. This was ultimately a key asset during their sale to a publicly traded media company.
“Looking back in your version history for that perfectly written page”
Almost every custom CMS we’ve built in the past decade has had version control. Version control is actually not a difficult concept to master. Simply save a new version of a piece of content on a timed basis or on user input and allow for a repository to quickly revert back when required.
If it sounds simple, it is because it is.
“Customizable access to specific content for specific users”
This simply comes down to user permissions. Every CMS we’ve ever made has this function. Creating user permissions is something almost any web application framework has made simple these days. I wouldn’t sacrifice a customized workflow and the chance to build a valuable asset for your company on account of a feature such as this.
“Being able to schedule content publishing for 2:00 AM on Sunday rather than having some poor schmuck stay up to click a button”
Again, I believe the original author may have been confused about how custom CMS systems work. I would remind everyone that the largest media companies in the world—including the New York Times, the Guardian, CNN, the LA Times, NPG, Hearst, Condé Nast—use customized systems.
Now, I did use major media corporations as examples to prove that custom CMSs have credibility. But in our experience, there are many small- to medium-sized businesses using this technology as well. It doesn’t take a large amount of resources or budget to make a custom CMS work for a business of any size. If the desire for freedom and flexibility exists, there is always a pathway to build the perfect solution.
“Adding analytics scripts to every page on the site with two clicks”
Again, this is a very easy feature to build from the ground up. All of our custom CMS solutions offer a tool to allow header/footer tagging and control. In this case, adding or deleting analytics code isn’t even a feature that would be used on a regular basis, so using it as a deciding factor or an argument for going one way or another in making a technology decision is silly.
“Caching mechanisms that have been tested under the most extreme load”
This is an interesting point and an area where off-the-shelf solutions are actually very ill-equipped.
Sure, CMSs such as WordPress have plugins available to assist in caching the front-end files to enable faster delivery of content and increase the capabilities of a server. But caching only goes so far.
Has anyone ever tried to load balance WordPress or Drupal for maximum scale? How did that go?
The custom CMS of today handles scaling better than ever before because of the amount of architecture options it offers. The most appealing option is the possibility of publishing site files directly to a service like Amazon’s S3. Most content-heavy sites or even informational marketing sites can be served in a static fashion—with a full-featured CMS that includes all of the features reviewed here, no less.
Where there is a need for interactivity, you can do that via API to a headless CMS hosted in a centralized location. To argue that integrated systems like WordPress, Drupal, or any other CMS that is based on that architecture can be scaled to the same extreme as a headless system is not something that can be argued unless you try to decouple WordPress or Drupal itself.
And in that case, why bother? They weren’t ever intended to do that in the first place.
“Pre-build modules and widgets that save you weeks and months of custom development”
This is an interesting argument. Plugins indeed do make it much easier to extend the functionality of off-the-shelf platforms. However, there are two points to consider.
First, they are the number-one source of future vulnerabilities. You have to continuously keep them up to date or run the risk of exposing your site to attackers. This means constant updates, which must also work seamlessly with how you have integrated the plugin and any other plugins it may be dependent on.
I think the bigger concern with plugins is that they just bring too much complexity to something that should be simple. Plugins have to handle hundreds of use cases when perhaps you only need one. This level of complexity means bloatware—software that is going to slow your website down unnecessarily. This can be avoided with just a little bit of qualified custom web development.
Another important thing to consider is that anyone who specializes in custom CMS development has already done all these integrations in the past anyway. So it isn’t as if a request to add a form, integrate a caching mechanism, or any other extension of core functionality is very complex. Most custom CMSs will be based on a coding or application framework, which will enable one to easily build these features—assuming the developer knows what they are doing.
“A platform that can be taken over by new developers when the current ones leave”
This is only an issue because of the inundation of the web development industry with folks who call themselves “developers” but really aren’t. A custom CMS built on a LAMP stack, for example, would have a talent pool of millions of qualified people who could make the necessary updates and changes.
This also makes the broad assumption that all CMS developers—those working in off-the-shelf software exclusively—are at the same skill level. We’ve seen horrible installations of WordPress and Drupal, for example. The argument being made here is implying that the complexity of custom solutions makes it hard to hand off, but in reality, we’ve seen WordPress solutions that, after hand-off, needed to be rebuilt because they were installed with flaws that prevented further improvements.
“Industry case studies that prove that you’re making the right decision”
Every customer that comes our way during the sales cycle tells us about their major issues with the CMS they are using today. Regardless of case studies, one size never fits all. There are many case studies that point to the efficacy of custom-developed solutions as well, so it is important to thoroughly review all the options available before deciding on a platform.
“Literally hundreds of commercial and open source options for every conceivable combination of requirements”
I feel like this is just a way of saying that every single project is always the same, and that everything you’ll ever run into in terms of a specification or architecture is completely similar to something else out there.
In the custom development world, this is a pretty foreign concept. We deal with specific, custom workflows, business logic, and high-level commercial transactions on a regular basis.
One example: We have a client who has a strong online marketing presence for their long-term auto rental business. They wanted an integrated system that would allow for content management, as well as serve as a system to manage their transactions. This meant a unified suite of tools that would control not only the website content, but also the inventory of vehicles, options, and pricing schemas, in addition to customer transactions and data. Their pricing model is complicated with different rate structures per vehicle type, additional options, and rate discounts that are applied to different rental terms.
What combination of tools off the shelf would have accomplished this task?
“Support!!! If one thing is consistent in the CMS world, it’s that support is worth paying for. This is why Drupal and WordPress, free CMSs, are big businesses.”
It’s a bit confusing to the end user when they realize open-source software doesn’t mean they get actual support.
For example, Automattic is the main commercial enterprise that supports WordPress, and they do offer plugins and support. However, keep in mind what their support plans look like. WordPress VIP is the enterprise-level support plan, and they start at $5,000 per month for simple blogs. More complex sites and applications go up to $15,000 per month. This means a corporate presence hosted on WordPress VIP will cost you $180,000 per year—not to mention your initial design and development costs—to get the site off the ground.
If $15,000 per month is the price at which the leading contributors to the WordPress platform value monthly maintenance and updates, why would anyone choose a platform that requires that expense to simply keep stable?
In conclusion, I want to gently take a step back and say that off-the-shelf solutions do fill a valuable and necessary part of the CMS landscape and digital ecosystem. Clearly, a small informational site can run well on WordPress and a document-heavy site can run well on Drupal.
The problems arise when “developers” assume they can handle every single scenario all the time. Industry professionals are making decisions en masse to support or specialize in one particular platform. And as they see possible projects come their way, they will always find a way for each project to be done on the platform they prefer—even if it isn’t a great fit.
After all, you have to pay the bills, and development agencies aren’t keen on saying no to a lead. Like the old adage goes: When all you have is a hammer, everything looks like a nail.
As an industry, there should be much more openness to the need for a vibrant custom CMS development community. Even if the use case frequency is 1 in 100, when it makes sense, it makes sense. Many companies are investing countless dollars on solutions that don’t fit their needs, only to experience frustration, inefficiencies, liabilities, and added costs. As professionals, we owe it to the end user—the client—to properly diagnose and recommend all solutions, even if they require a custom approach.