I disagree.

First of all, I think it's ironic that you put this in an ExpressionEngine category and include a link to EE when EE isn't much different from an "agency" CMS. In both cases, it's a commercial application maintained by a corporation. Where EE makes a solid choice, is in the community of people that use it, understand it, and develop for it. Any agency would builds a CMS would likely hope for the same.

There are plenty of factors that are involved in making a decision to implementing a CMS and whether it comes from an agency, from a company dedicated to the task of building a CMS, or via open source, the "what if the company goes under" falls further down the list. The idea that you'll be stuck with an unsupported application can occur in all of these cases. One way to reduce this risk is to go with well-established platforms that have been around for years, like Drupal. The longer EE sticks around and more successful EE is, the less risky it becomes. But to repeat, this is a factor that should fall low on the priority list.

More important is how usable an application is and how well it fits within the flow of how a web site is maintained within an organization.

I think you present some good reasons, but I also think some of those reasons can go both ways. Having been on both sides of the fence, and also being involved in building a CMS, there doesn't seem to be a clear answer for every situation.

1. I have worked in a corporation that spent an enormous amount of money trying to pay someone else to put their Content Manager + Shopping Cart in order. Problem is, those 'CMS' systems weren't flexible enough to fit in with the particular business needs. This same corporation also threw a boxed CMS at their Intranet solution, only to be frustrated by the fact that no one ever used it or knew how to use it. Sure, it had all the bells and whistles - but none that they needed, and everything they didn't. They simply thought throwing a system like that at it would solve the problems - truth is it created more.

2. I have worked with smaller organizations what want a CMS so they can have control, only to completely butcher their online presence by having that control. Sometimes the control doesn't need to be in everyone's hands - it needs to be in the hands of people who know what they are doing. When you get people who know what you are doing, then they might be annoyed by the dumbed-down tools available to the CMS.

3. I have contracted with other companies who refuse to go custom and fit their needs, because of the hypothetical 'you might get hit by a mack truck tomorrow, and then who would build it' (I hate that quote, by the way). The truth is, as you have said here, companies change, people move in all directions. Thinking that a CMS will fit your needs no matter who comes or goes is wishful thinking. It's also wishful thinking to think you will find a CMS that can switch at the drop of the hat to fit your new business model or approach. All of this still takes work, by people who know what they are doing.

4. I have worked with people who want a CMS because someone told them they needed it, but then still let the site sit stagnant because they simply didn't have the time to update or maintain it. Again, in comes having people who know what they are doing taking the reins with things.

Truth is, there is no perfect solution out there. There are a lot of good systems and frameworks, but no perfect system that fits the many intricacies of some businesses. So should they buy off the shelf and try and morph to fit their needs? Then what happens with scheduled maintenance and updates? Are their changes wiped out?

The other truth is that just because everyone can publish on the web, doesn't mean they should. That's why there are professional web developers who understand the goals and the environment to help a company be successful.

I am not for or against a CMS - I just think there are many different things that need to be thought through when developing a site, and sometimes that does mean that it requires a knowledgeable developer to build a custom system.

Geof,

I agree to some extent. It's always a best tool for the job scenario.

Lots of large CMS products are overkill for tiny websites and vice versa.

The benefit of a commercial/professional CMS over a homegrown CMS is that typically a commercial CMS has a community and has evolved over time.

I've crossed paths with several organizations and businesses on proprietary agency built CMS's where the agency went out of business and the CMS was no longer supported. It's an alarming situation to be in.

Jonathan's point about an agency built CMS having a community of users seems improbable to me. In my experience that contradicts the whole point of the agency CMS. Are there some examples of such a creature?

I can imagine the argument being made between something like EE or Drupal and a completely custom app designed with a particular client's needs in mind, but I don't think that's what Geoff is referring to.

Jonathan - I thought about including a list of what I'd consider to be excellent CMS products (including Drupal) but obviously decided otherwise. I did this to try and remain as impartial as possible. I can't hide my EE bias, but I can still try to be fair.

Nate - As you'd imagine, I've also been in all of those situations. Isn't it amazing how, despite living and working in different areas of the world, the problems never seem to stray from the norm?

I agree a commercially available, professionally supported CMS does not solve every problem, and in fact, this type of software can create unique problems of its own. I just feel the number of these issues will likely be fewer and/or less severe than that of an agency-produced CMS.

As Jonathan has also stated, every product and company has potential to go under regardless of their operating model. It just seems to me that a more distributed and open CMS would still be more future-proof than a closed loop system. All software needs developers. As a client, I'd rather have more developer options than fewer.

Andrew - The product evolution and maturation you speak of is key. A good software product is always in development; whether those are small or big changes, it doesn't matter as long as there is a visible captain(s) at the helm.

Christy - Yes, that's not what I am getting at. I don't want to compare products, rather the potential experience of the paying customer who has to live with the system.

This made me think about job security in one sense. Many feel safe if they work for the larger tech companies but the security is a myth because we're now again seeing the safe-bet type of companies lay off employees by the dozen of two.

Well, it's the same with going for a safe bet enterprise-y CMS, if the bloat up or change directions or discontinue the product you're screwed too.

Your point on data portability is well taken. Agreed, there should be a clean exit path if you want to take your site and host it elsewhere.

Early in the new year we're adding the "export site as HTML" feature to give our YikeSite customers piece of mind (and also if they simply want to host it on their own servers).

Great post Geof,

Lots things to consider here for sure. As a web service provider with a "home grown" CMS we get the question all the time: What happens if you go out of business?

I find it interesting that the web site is a very dynamic place, so dynamic in fact that every 5 years or so we end up doing it all from scratch...a lot. So having a back end that will last for the foreseeable future is important, but that can be a lot shorter than you might think. Technology just moves way to fast. Today something works great, next month it is old and stale. I guess that is where the constant growth in software is important, but we really find that our customers hate a lot of change or "improvements" - generally.

My gut tells me companies pick a service provider they trust and then go with what they recommend. That relationship can change annually or every 5 - 6 years. That web site is going to get moved around a lot over a decade.

I think the most important thing is data portability regardless of where or how it is built. I like how Jeff K. Ward is thinking. It is a great start and gives customers lots of options. Ecom and other complex functions that require persistence don't quite work, but a least your content can be moved in a pinch.

Thanks Geof,

ps CMS products are really becoming a commodity. Unless you have a niche and have a very specific feature set, off the shelf is the way to go.

While you are asking a valid question in your article I have yet to meet a client that really needs any kind of CMS at all.

I have developed a few custom CMS solutions for our clients in the past, I have also implemented some commercial systems a couple times. All of our clients want to be able to edit every single bit of content on their site. Yet once the project is out and we check back a few months later, in 90% of all cases the site is untouched. Maybe a new news item is added.

Now, wouldn't it be much cheaper for both parties to just deploy a pure HTML solution and make necessary changes now and then? Initial cost would be considerably lower, clients don't need to familiarize themselves with any kind of management system (chances of butchering their own site are going down as well) and everyone is happy.

So, I guess instead of asking yourself a question if you should go with a commercial CMS or start building one from scratch, we should ask our client if they really, really need a CMS and are willing to spend a few hours to learn how to use it (it's not MS Word, no matter what we do).

But coming back to your initial problem - I believe that reinventing the wheel for the n-th time simply isn't worth the time or money invested. Any commercial product with a large user base (e.g. EE) will be by far better documented, tested, etc. than any solution built in-house just to meet the needs of particular client (unless you have been developing your CMS for past 2 years)

I agree with Geoff except on his choice of CMS. I found Expression Engine to be a big let-down when I used it for a client. I hugely prefer WordPress.

Maybe, it's just me but has anyone else found Expression Engine to be disappointing after all the rave reviews?

Jeff - The "export site as HTML" feature sounds fantastic. I'm intrigued as to how this would work for complicated websites: customer accounts, e-commerce shopping cart, custom analytics tracking and other features. Is that what you have planned or is the export more for simple content?

Peter - I agree, constant rolling change can actually be damaging for end-users. If every time you log into the CMS you're presented with a barrage of updates, it can make the software feel unstable.

Chris - Agreed on all points. A more mature product that is actively being improved and developed is typically a much smarter route to take.

Levi - I've rarely found EE to be lacking for what I need it to do. What particular aspect(s) do you consider a let-down?

@Chris Danek

Very well put.

@Levi

Please tell me you were building blog client sites, because anything outside of that, WP falls flat on it's face as a CMS. EE doesn't shoehorn data like WP does (database wise), and is a much more stable solution to solving problems outside of a 'blog'.

Thoughts?

@Levi: I had a project where EE ended up being a poor choice, mostly due to the design of EE, itself. The upload process for assets is woeful, with two different processes depending if you're selecting an existing file or uploading a new one. The client only updates the site twice a year so in the end, it just made more sense for him to email me a CD and upload the assets myself.

@Nate: I'm interested to hear more detail on why you think WP is a bad solution as a CMS. I've found it to work great. Is it just the schema design that you don't like? I admit that the WP schema is a bit cumbersome but I've never found it to be impossible to work with and I rarely have to directly interact with the DB anyway.

My main problems with EE were its control panel user interface and the templating system.

The EE control panel just feels like something that would have been excellent 5 years ago but is really showing its age now. Also like Jonathan mentioned, the asset management is pretty archaic—especially when you compare it to something like the latest release of the WordPress interface.

Storing the templates in the database and using a custom tags to render data makes sense in theory but I found it frustrating in practice. I much prefer WP's approach to templating by keeping it filesystem based and using php instead of custom tags. It speeds up developing on the fly and debugging. Also, it's far easier to package up themes. Of course, it could be argued that by allowing php in the templates WP is encouraging poor coding practices.

Finally there's the whole thing about EE having a proprietary license and WP being free and open source.

I'm not totally knocking EE. People like Geoff prove that you can build amazing sites with it. I haven't dug into the guts enough to make a truly sophisticated evaluation. But I just know that I'm much happier with WP and I've never encountered a reason to return to EE.

Thoughts?

@Geoff - Well, YikeSite is targeted at static smallish websites so we don't do e-commerce or shopping carts. So the "export as html" will work well in most cases.

A little out of my element here, being non-technical and having worked mainly on the client services, content creation and marketing side of web...but what is clear is that clients need to have realistic CMS expectations. I think there are many clients who think that a CMS will allow them to do "everything" seamlessly and then a "I can take it from here" mentality.

Regardless of which way the CMS is built, there either needs to be an understanding of how much technical know-how is required and how much $ is consistently required to maintain it. I have worked on the content (non technical side) of three commercial CMS systems and one custom-built CMS.

Each one was different and required a different approach. For example, I am an EE fan (disclaimer: Subvert set me up) and love the ease at which I can create content, upload video, images, etc...but don't ask me how to create a new call-out next to the main navigation (as an example). I have also used Joomla and realized that it is much more cost-effective to get a professional to maintain the site, as knowledge of code is required to even deal with basic CMS functions. Finally the custom built CMS was great to use and built to allow maximum client control, but that may have only been successful since I had a team of programmers to call on, once I identified a problem.

All to say, that regardless of which CMS approach, clients will need to either invest in furthering their technical knowledge or expect to pay a professional occasionally to keep it working.

Geof, I understand the points you bring up, but I think no matter what CMS you use, there is always a chance something can go wrong. I think one important point to keep in mind, is that all websites are temporary.

Yes, an agency can go out of business, or a freelance designer can get hit by a bus, but a server hosting an EE site can also crash without adequate backups.

This is why I think it is crucial to make sure the client has complete ownership/control of the actual domain name (through whatever registrar that may be), because the domain name is the only permanent feature of a website.

Levi - Custom tags is actually what I prefer about ExpressionEngine over Wordpress. I believe the EE templating system makes more sense and is far quicker to build with once you get used to the syntax.

Dennis - I appreciate the perspective you're writing from, as those points are something we need to keep at front of mind when proposing a CMS solution.

Aaron - Correct, no delivery platform (agency-built, commercial CMS or hosted CMS like Reflect) is immune to reality. What can hopefully minimize the number/magnitude of these situations is a solid company behind the product who will be there when things go wrong.