Content Management Systems are a dying breed

Based on my experience and thoughts over the years, and feedback from a number of very smart and talented people, I believe that Content Management Systems (CMS) are far from the promised savior, but rather the bane of web sites.


Back at the end of the 1990s, people wanted to start controlling content creation on the web. They were offered all kinds of hacks, and to be gentle, let’s just say they were “a bit varying in their quality”. Most of the time, there were no support or documentation (since developers just want to code, right?).

To fix this situation and bring some stability to the market, a number of CMSs were developed, and to this day, they keep on popping up around every corner – I bet of majority of the developers out there has, at one time or another in their career, worked on building their own CMS. The initial idea with them are good, trying to collect knowledge and experience, but all of them, without exception, fail sooner or later in some aspect.

“One size fits all”

The problem with any CMS is that it tries to accommodate to as many needs as it can, both from a developer, business and editor perspective. This also goes for a market filled with a vast array of different ideas, hopes and desires. Basically, common sense tells us that the result, at the very best, will only become decent.

Virtually any web site that is sold as CMS-controlled is easily set up and installed, and then months, or even years, are spent “configuring” it – and by configuring, I mean patching, fixing, mending and hacking it to remotely meet the usage wanted by the customer.

What I rather suggest is that it is our responsibility as professionals to not just throw a CMS at our customers, and then have editors and developers alike being miserable, but rather to listen to our customers’ actual needs and then custom build what will be best for them. It is also inline with working in an agile manner, developing what should be there, instead of wasting money and time on a CMS filled to the brim with bulky features that most people don’t need nor want.

“Don’t reinvent the wheel”

“No, no, don’t reinvent the wheel, don’t brings us back to the wild west-mentality of before!” I hear you cry out. That is very far from what I am suggesting. Instead, I think the scale of developers’ choices look something like this:

  • A poor developer uses only one CMS, and recommends it over and over, no matter what the customers ask for.
  • A decent developer knows about the options, and chooses a CMS he/she thinks will be the best (rather, bring the least amount of implementation and maintenance pain to everyone).
  • A good developer doesn’t choose a CMS, but rather cherry-picks the best components out there and binds them together in an optimal result, custom-tailored for their customer.

What I mean with components are specific things, that could be found as parts of an existing CMS, but function stand-alone as well. We’re talking WYSIWYG editors, data saving, friendly URLs, tree controls etc etc. What you will get from this is choosing the best tool for the job, for each specific part. You can scour the market until you find exactly what you need, and if you do a responsible choice, you can find the best for a certain task not only out of code and maintenance perspective, but also in regards to community involvement, support, proper documentation and a huge number of other people working with the same thing.

Your part will be more like a conductor directing an orchestra, binding all small and independent things into the best and optimal end result. Naturally, and this is very important, apart from delivering this to the customer, you should also offer support for your part in this, tying all this together in a beautiful architecture.

It will also give the customer the option to, in the long run, just change or upgrade the components they wish to change, instead of the enormous undertaking of upgrading an entire CMS. Think one part out of all isn’t optimal? Just get a new one, while doing it in a very cost-effective manner!

They will be around

CMSs will, no doubt, be around for quite some time. But my belief is that instead of focusing on products, it’s vital both for our customers and the climate of the web, that we start taking some pride in building the best possible things we can, instead of just having our hands tied behind our backs by a CMS.


  • George says:

    In my humble opinion CMS products have evolved from software products to development frameworks. I don't think CMS products are dying – rather they are evolving to provide developers with rich frameworks to respond to client requirements.

    My (mostly) CMS of choice for content sites is ExpressionEngine. It is now built on CodeIgniter, a fully featured PHP framework. This means the software can be extended by a competent developer easily.

    As such for me it is a symbiotic relationship. A CMS product takes care of standard CRUD actions, security, caching etc and a developer extends the CMS to give the client exactly what they want.

  • Interesting view, I sure hope the right people will join the discussion here (it could get intense).

    From my part, I've worked with different kinds of CMS and I usually group them into two categories.

    1) the CMS has a lot built in by default, but requires much headache when something must be added. Example: Polopoly, EPI-server.

    2) the CMS is modular and built with extensions in mind rather than to deliver a rock solid product right out of the box. Example: Drupal, SilverStripe.

    I myself prefer the later personally. A category 2 CMS has potential to survive, a category 1 CMS I believe will face problems in the future.

  • J. Dichev says:

    An insightful article – thanks. I agree that 'one size fits all' problem and some developers' choice of only one CMS for everything are the main problems to relevant CMS solutions.

    In @George's comments I see what looks to me like a good solution so far – CMS should be build on framework, which should make them easy to extend and modify to make them relevant to customer's needs.

    My personal experience is: after several years trying to cope with what's currently available as CMS choice – I build my own simple CMS based on the Zend Framework which so far proved easiest to adapt to particular client's needs in a natural manner.

  • I am with you on this. I never worked with a really good CMS and I think it is because there is no such one, and there can not be such one. Customers needs are too different to bake it into one big CMS.

    I personally like web frameworks like Rails or Django much better. There are more flexible and if you build some default modules you can have your own mini-CMS as a startpoint and rapidly build and add more functionality when the customer needs it.

  • I see that too. With the rise of frameworks and the need of websites to act as web applications. The CMS Side just becomes a generic plugin.

    But we seriously have to rethink our toolchain – I coded PHP for years but will it be the right choice when things get tougher? And on the interface side – do I want my customer to be able to drag new content areas onto his website and then edit them with all the power a rich text editor provides… Or do I just want a clean information architecture that is pure and that will survice several redesigns.



  • jhoysi says:

    An interesting article, and while I definitely agree, there is one factor that hinders a lot of companies from getting what they actually need out of their web presence – in terms of a CMS or otherwise – price.

    Custom-built is expensive, or at the very least, looks more expensive than an out-of-the-box approach. The decision-maker in a web project, regardless of how much we pursuade and recommend, is often someone who doesn't understand the technology enough to know that spending more money up front will save them money in maintenance and "configuration" in the long run. Even when that is explained, for some reason, it all comes down to the two raw set-up figures that are presented to them, with the maintenance costs ignored.

    Strange, but true in my experience.

  • Steven Clark says:

    Its a prickly can of worms you've opened this time, Robert. I have to admit to a pet hate for those who answer the telephone every time with 'What you need is a CMS'… when, after arguing for some years with one guy he finally admitted that only one per cent of his clients ever ever edited a single page… the CMS sounds great to the customer in theory on paper but IMO its more often than not (barring larger orgs of course) the first step in a downward spiral of compromise – the first being cheapness, of course.

    I would hope that the direction of our future, rather than being simply about a choice of technology as such, will become a smarter choice of business to pursue outcomes which make a positive return on investment through the implementation of the right tool for the right job in each instance. Not something that they must have without a purpose. I mean a website that actually has a reason to exist in the business world and brings some form of positive back to the company – money would be a good start).

    I like the differentiation between the different types of developers who use CMS, by the way. How true. But I guess skillset, experience, budget and time will all dictate their own footprint on the CMS option.

    I recommend starting at the other end of the question with clients. When the next one walks into the door, rather than trying to sell to them give them a question.

    'What do you think the website can do for your business'?

    Make them quantify the reason, pin them down a bit, ask how they analysed it. Its only when the customer fully understands their business need that you can understand it and maximise their opportunity with the right solution… if that makes sense. I see very little analysis.

    Oh such a can of worms Robert… now if only we can tie up all those schoolboys and schoolgirls selling rubbish for chump change. πŸ™‚

  • […] Content Management Systems are a dying breed […]

  • Good luck doing all that choosing, building and maintaining for $2000 up front and $200/year.

    In many cases it's better to fit your requirements to a product than the other way around.

  • The only thing I disagree with in this article is the title—CMSes are not dying at all, they will continue to expand because there is a huge market segment for them.

    I've been building websites for over 15 years now, and I've done it all, first by hand, then with lightweight CMSes, then heavyweight proprietary CMSes, then open source CMS, then lightweight proprietary module-based CMSes, and eventually a few years ago I just decided to go all Rails with my career.

    Most recently I worked with Expression Engine and Drupal. Drupal is an amazing feat of engineering. It's unorthodox, but it's amazing the amount of customizability and hooks they cram into an out-of-the-box product. The problem is that a one-size-fits-all solution is necessarily going to make a lot of assumptions that don't apply to everyone (or really anyone when considered in total), and this manifests itself by overhead—both performance and conceptual. Very early in any project, you find yourself making small design and functionality tradeoffs just to fit the huge architecture you've inherited. Some of these tradeoffs can end up being serious usability impairments, but the complexity of the modules you are using and lack of solid test coverage and integration testing means that the cost of making a conceptually simple change suddenly balloons out of all proportion. With a standard CMS you come out of the gate at a full sprint, but very very often you can be running straight into a tarpit.

    This is why I loved Rails so much. Rails attempts to only provide with the basic building blocks that are common to all web applications, and it provides them in a low-level way so that you can assemble them however you want with no conceptual or performance penalty. In short, Rails / Django / et al are just operating at the right level of abstraction for building really great websites. Estimating software development costs is already quite difficult, but with Rails its a couple orders of magnitude easier than with (for example) Drupal.

    Here's the kicker though, most clients don't have the budget for a custom application. Just a decent design alone on any kind of non-trivial website is going to be upwards of 5 figures, assuming proper UI design and a few non-trivial workflows. I used to work for an agency in a non-tech-center market, and the majority of clients considered $5000 to be a huge sum, and they would bring insane requirements. Literally the only thing you can sell these people and still keep a shirt on your back is a pre-packaged solution. For most clients this works out okay because they don't understand design or usability anyway, and once you train them how to use it they are happy to muddle through. Occasionally you can get very difficult clients, at which point you need to just dump them like hot potatoes to be swept up by the bottom-feeders. I shudder to think how those relationships work out between the overbearing no-respect client with insanely unrealistic expectations and the incompetent unhirable freelance-site troll. I suppose it comes down to a battle of wits and wills to see who can take greater advantage of the other.

    One thing is for sure though, there is a lot of business being done well below the level of the custom app. Hosted solutions will probably eat into that a bit, but there's still a huge market for self-hosted CMSes.

  • Robert Nyman says:

    Thanks for for good and thoughtful comments!


    I think your and mine opinion doesn't differ that much. I definitely agree about using components for basic work (like you mention:CRUD, etc).

    And I agree, development frameworks of different sorts are great. Only difference is, though, is that I think that most CMSs have become much more and too bulky for that – I'd love for that to change.


    I generally agree about your categorization. I think that CMSs do have a chance to survive (rather, read: become useful) if they become as lightweight as possible, and extremely modular.

    J. Dichev,


    I think that, generally, just a good development framework paired with good and easily changeable components are suitable for most scenarios.


    Glad you agree! And definitely, I think we will see web frameworks replacing clunky CMSs more and more.


    Absolutely, it is always a matter of using the right tool for the job.


    That's a great point! I would like to say , though, that in the long run, it is seldom more expensive with custom-built (rather the opposite), if you had the right developers doing it.

    However, for example, here in Sweden, one of the most used CMSs comes with a hefty license fee – money that could instead be spent on developing and choosing the right components, so it's easier to argue in such a case.


    Someone had to open it, right? πŸ™‚

    And I totally agree: it's about making the customer's business better and in turn improve the end user experience for their customers.

    Thomas Beagle,

    <blockquote cite=""&gt;

    In many cases it’s better to fit your requirements to a product than the other way around.

    From my experience, I definitely don't agree with that statement. What you end up with in the end is a mediocre result at best, while wasting the customer's money on patching and hacking the product to remotely fit the actual needs.

    And as mentioned above, the license fee for some CMSs that cost money vastly overshadow those figures you mention there.

    Gabe da Silveira,

    Great comment!

    Regarding the title, I would say that it should rather have been "(Most) Content Management Systems are a dying breed (unless they change their way and become incredibly flexible and modular)".

    In regards to web frameworks, I think they more and more will shape the future of development on the web, and replace CMSs as we go along.

  • Richard Fink says:

    What you are talking about is a big, big problem. Made worse by the web being a young medium.

    Even basic HTML editors like Dreamweaver are pathetic, IMHO. Too much variation, still, on the client-side to lower the learning curve.

    Nothing ever works right "out of the box". But it is important, every now and again, to ask "Why?"

    Regards, rich

  • tedeh says:

    I was expecting an article on how WordPress will power every web site in the future by leveraging "hacks" and jQuery, but your post was actually both thoughtful and ultimately true.

  • Robert Nyman says:


    Yes, it definitely is a big problem. I guess one of the reasons why in this case, is that the "box" tries to cater to too many things, thus failing in delivering in most of them.


    Thanks, I'm glad to hear that you appreciate it!

  • Diego Perini says:


    even if some failed with their CMS project objectives it doesn't mean you can make it as general as you are doing, after 10 years using our own WEB assembler tool I can say I am quite happy and see a great future for it. What we have is a Visual Site Builder.-

    The pages does not exists as files they are built/served from recursion chains on a DOM representation of the page in the database, it allows for modules in any language to place content in the middle of the page without the module having a knowledge of the surrounding layout, it is a complete separation of layout and server-side processing.

    For sure, it still needs competent people (CSS+HTML) to setup create the layouts and the templates but they can easily import them from an existing library if they don't have the skills themselves, once that is done everybody is able to do modifications and small adjustments using a nice graphic interface and a simple Rich Text Editor.

    The modifications can be done in real time on the published sites or can be done on copies and finally imported once finalized. Users and/or developers are free to use whatever Javascript framework in it.

  • Robert Nyman says:


    First, let me say that if you and your colleagues are completely happy with your WEB assembler, I'm happy for you and think you should keep on doing it.

    However, from my humble perspective, editing code through a visual/rich text editor seems like something I personally wouldn't like (as opposed to seeing and reading the actual code), and I believe that you can only come so far with text editors.

    Still, best of luck!

  • Diego Perini says:


    RTE in our product is not to edit generic code, layout, javascript or CSS … it is just to let users write/edit their textual contents in the boxes.

    Where should users type their text contents, in Notepad, Dreamweaver ? Or are you saying they should pay ASP/PHP professional devs to do that too ?

  • Simon Wells says:

    Interesting article . . thanks.

    If CMS is dying, I wonder what will be replacing it?

  • Tony Sova says:

    Dying breed? Hardly. More like the next generation leading into future technology. The fact is if you want a powerful website at low cost there is no way to custom build "tailored to your clients". Most clients don't even know what they need or want anyway and really aren't willing to pay for it in this economy.

    The problem isn't the CMS it's the training that most clients DON'T get. Using a WYSIWYG editor requires hands on, personal training and not reading some book or watching a video. Since the editor is generating HTML most people don't understand the reason things get styled incorrectly.

    The biggest benefit from a content management system isn't in the editor part of the system anyway. It comes from the framework that is used. By using a CMS you avoid creating bugs from custom code and a user interface that is far easier to use that reading PHP.

    The sheer volume of development being created speaks to the community and the sharing of information which is so much more powerful than any proprietary system.

    It's hard to believe that millions of website created by the top three content management systems (WordPress, Joomla, and Drupal) on the planet could be wrong or, as you say, a dying breed.

  • Continuing on Anders Ytterströms distinction of two types of CMS:es I can agree with you Robert that the CMS:es that has a lot built in by default and that are hard to change are definitely heading down the wrong road and we're already seeing that they have a hard time keeping up with new standards and trends.

    But then there's the other CMS:es that are more framework-like – Drupal being one of them – that are recognizing the problems that you're pointing out and trying to address them. Eg. Drupal 8 will if I remember correctly for the first time have one maintainer for the framework part of Drupal and one for the CMS-product.

    I would also like to say that CMS is a very bad term that can be used to describe most modern websites – custom coded or platform based. It doesn't really tell anything more than that the site's content can be edited directly through the site – the technical solution behind that can be both good and bad.

    All in all – whenever the tool becomes the solution instead of a way to reach the solution something has gone wrong – no matter if that tool is called a CMS or some other fancy thing. If one tool doesn't suite the solution – pick another.

  • Robert Nyman says:


    Sorry, I misunderstood you then. Using some kind of WYSIWYG is naturally ok in my book, based on what WYSIWYG component will the best for your needs.



    Like I mentioned in the article: developers choosing and pairing various components together into the best tool suitable for the job at hand.


    As you can see with most web sites built on a CMS, the results are far from perfect. And as I mentioned, it's mostly not about custom building, it's rather about taking a number of smaller components, best at what just they do, and put them together into what's most optimal for the customer's needs.

    I think training of editors is the least of the problems we have, although, naturally, the more they know, the better it is.

    About your mentions of WordPress, Joomla and Drupal: the argument that it is used by a lot of people doesn't really have any indication whatsoever about its quality; let's just look at the Windows market share in comparison to what people think about their operating system.

    I believe the reason that they are well-spread is because they are, overall, easy-to-use, which of course it's a good thing, but I think they need to be more modular to be reasonable choices for a quality end product.

    But are CMSs actually dying? Of course not, at least not in the near future. But to they are dying as plausible choices for building quality end results.


    Good comment!

    What I know and have heard about Drupal, it seems that they are at least moving in the right direction, and I hope strategically what's needed to be the top choice for delivering the best web sites.

    And yes, the name CMS is used for so many things, it doesn't really have any good value connected to it anymore.

    <blockquote cite=""&gt;

    All in all – whenever the tool becomes the solution instead of a way to reach the solution something has gone wrong – no matter if that tool is called a CMS or some other fancy thing. If one tool doesn’t suite the solution – pick another.

    You are absolutely right, and I completely agree with you here. But, just to add: picking another could, and I believe as of right now, should be looking into the option of combining smaller components than by default just choosing any kind of CMS.

  • Interesting post and discussion!

    I think lightweight CMSes like Drupal, WP, or Expression Engine are fine if you have a non-technical client that wants simply wants an "internet presence". If you've built a couple of those sites and you've found a few quality plugins that work well, you can get something out the door very quickly. It's all about picking the low-hanging fruit, and it is nothing to be ashamed of. Commoditization happens in every industry eventually.

    If you're building something for a more understanding and demanding customer, go for a framework like Sinatra, Rails, Django or Wicket. It will help you out with the boring stuff like routing & CRUD and lets you focus on the interesting parts.

    It comes down to price and how agile the client is.

  • Robert Nyman says:


    Absolutely, we have to be pragmatic too. Sometimes you just have to offer them something right away.

    But, I believe that such a thing will only be decent at best, as opposed to an experienced developer picking the best parts.

  • Diego Perini says:

    have to rectify then, I was not talking about CMS… and agree with most of what Pelle said. The task is obviously complex but if we want to come to some conclusion we will have to split things up.

    There would be many interesting parts in such a "tool", I will mention three:

    1) user "friendly" modification capabilities of content (both batch or live)

    2) server-side modules, only output naked elements and dynamic content

    3) ensuring correct output (tidy/w3c) and usability/accessibility rules

    modules, written in your preferred language (2) should have no knowledge absolutely and be unaware of the surrounding context they will be inserted into (1). Points 2 and 3 will require technical knowledge so not for the casual user, but point 1 should be the first objective of every one of the mentioned tools.

    After years making the UI more user friendly and writing documentation we are still spending most of the time explaining HTML and CSS (1) to users. I admit this is also a source of work, but that wasn't the real objective of the tool either πŸ˜‰ It remains for developers and slightly trained personnel (which is good).

  • Robert Nyman says:


    Ah, I see. πŸ™‚

    In that case, it seems very much in line with what I am proposing then.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.