There is a trend within web-agencies to use in-house content management systems (CMSs) for client websites. I’ve worked with a few of them and built one or two myself and to be honest in most cases they are a waste of time and resources.
Developers love to build things from scratch, by building a system from the ground up, they have an intimate knowledge of every part of it. Unfortunately, in a commercial agency environment, limited timescales and budgets force corners to be cut and these systems – unless tightly planned and controlled – can become a nightmare of kludgy code added to satisfy bespoke requirements for a number of very different projects.
The CMS landscape
Web-based content management systems are a fairly mature technology these days, ranging from high-end enterprise systems to well-supported open-source solutions and some recent projects designed to support the latest thinking in usability and web-standards.
Most of these system are under continual development, either by dedicated programming teams in the case of commercial software or by communities of coders, each lending their specialist skills to parts of open-source projects.
Agency built solutions on the other hand are generally only updated when a specific project requires it. The gap between the functionality offered by the agency’s CMS and that offered by the third-party alternatives grows over time.
Sensible use of resources
When an agency starts work on a project using their in-house CMS, it’s often the case that the developers need to do a significant amount of work just to provide basic functionality.
By using a suitably extensible CMS the basic functionality is done and dusted from the get-go, developer time can be more productively used in building any bespoke functionality within the CMS framework. An added benefit is that if the bespoke functionality is built in a modular way, it becomes a re-usable asset.
Who’s to blame?
Nobody really, or possibly everybody. The problem usually occurs when non-technical client-managers ask the developers for estimates on building a site to a certain specification. Developers naturally think in terms of coding the whole thing themselves, after all, it’s their job to build software.
One approach
A good approach is to try and match the requirements of each project to the capabilities of an existing system. The systems evaluated will depend on factors such as:
-
Budget
Depending on the scope of the project, a licensed commercial CMS may be required to fulfil the requirements. These can vary greatly in price so identifying such a requirement early in the project lifecycle can be paramount.
-
Hosting Platform
The agency will not always be able to specify the hosting environment for the site, the platform in use will limit the choice of CMS.
-
Familiarity
If the project requires some bespoke coding or complex configuration, it may be safer to stick with a CMS with which you have some experience. Reducing the learning curve is another good way to cut development time.
Third-party CMSs will not fit the bill for all projects, but it’s worth taking a little time to find out if you can skip weeks of re-inventing the wheel and set developers straight to work on custom functionality. You will also have the advantage that, with a CMS in place, your content editors can begin work populating the content and the front-end designers can be working on templates without the developer being a bottleneck in the production process.
I’m not suggesting that this is the case in all agencies, I know of quite a few who have embraced third-party solutions such as WordPress or Umbraco for even the smallest of sites. I also know a similar number of agencies who’s in-house CMSs I’ve either worked with or who’s employees have muttered “We have our own CMS, but we don’t really like to talk about it…”. I wish I could say I’ve seen a good agency-built CMS, but they seem to be in short supply.
Bookmark and Share
Digg This
Good post. Here at The CogWorks we used to use our own .NET based CMS which we were about to try and develop further.
We then came across Umbraco about 18 months ago, found out it did everything we wanted ours to do and more…so needless to say we ditched our CMS within minutes
We took the decision to solely concentrate on Umbraco development for every project no matter what size the client or project and it has been a great decision so far.
As far as we are concerned, there’s no need to waste resources building your own CMS when you can use a platform like Umbraco and spend the budget building better applications instead of standard CMS functionality that’s already there and freely available.
That sounds like a familiar situation. My only problem with Umbraco is the need to use XSLT for templates. It’s not a problem for me, having a development background, but it can be problematic when front-end developers need to make changes to markup. Without any XSLT experience it can still fall to the developer to be a middle-man in the deployment process.
Having said that, I’ve not investigated the new MVC-based version of Umbraco yet. It would be nice if there was a choice to create views using a templating engine such as nVelocity.
Very good thoughts.
Developers in agencies often need to answer very specific design decisions that are new and out of the standards. They know that you quickly run into trouble, trying to bend old standards into something completely different. So the question becomes: compromise on the design, do bending despite the inevitable problems or just make the solution. Doesn’t take much to guess the right answer.
As interaction designer working with many agencies, I’ve seen this come down too many times. As the author points out, it’s not a safe road to take. Each custom solution add future burden with upkeep and inevitable updates —something agencies rarely have any budgets.
To solve this, we created Bildy http://thebildy.com With Bildy, developers can drop in their own UI for content management and then code the functionality and look that they want. Assuming nothing means that you have custom data which you can turn into anything: HTML for sites, XML for Flash or JSON for Ajax. You’ll a have solid foundation and fast tools to make that unique design a reality –without hacking.
As Dave points out: you really should build upon some framework or product, what ever that might be. When upkeep and updates are taken care for you, you’re not digging your own grave.
Thanks for your comments, I’d not seen Bildy before but it looks like an excellent solution, I’ll investigate just as soon as I’ve finished wrestling with the latest bodged CMS that’s been dropped on me.
Thanks.
I think I should point out that developing Bildy and supporting it’s users is our main business, not a side project
Hi Dave,
I run a development agency and we build 99% of our client sites on the Umbraco framework, I agree with your article, there are still companies out there who insist on building their own bespoke solutions, but that just makes us more competitive
Chris
I just realised that there’s another point I should have covered.
When the developer of an Agency CMS (inevitably) leaves the company, unless they have given an extensive handover or written good documentation (like THAT ever happens!) – The developer who takes his/her place has to learn the system from scratch.
For third-party CMSs it’s not hard to recruit somebody who already has experience using the system – minimising the cost of switching developers or adding developers to the team.
Can’t believe no one has mentioned how cold the room must have been in the “My CMS can kick your CMS’s ass” photo!
The chance to illustrate a post with a big pair of tits was just too good to pass up
Nice insight to someone who wishes to develop their in-house CMS. There are numerous CMS out there that gives what you want. It all depends on what features that you are looking for to management your site for the next 2-4 years. That planning is required for any agency to identify the right CMS solution be it open source or commercial ones to manage their site.