FullCodePress: Pre-built vs Custom?

Matthew Magain
Tweet

One of the most interesting outcomes of last weekend’s FullCodePress international site in a day event was that each team chose a wildly different approach to tackle their client’s site.

The Aussie team chose to use a pre-built, open source CMS (Drupal) while the CodeBlacks (Team New Zealand) chose to build their site from scratch.

Initially my thoughts were that the CodeBlacks had bitten off way more than they could chew. When I stuck my head into their room at the 11th hour (actually, the 23rd hour) the team was huddled nervously around one screen, while their programmer scratched his head and began doubting himself. However, full credit to the team’s programmer, Mark Rickerby: despite having had no sleep and being under enormous pressure he managed to resolve whatever technical issue it was that was holding them up, and his team came out victorious.

In the post-mortem, the New Zealand team asserted that a custom build was the right solution for their client; given the scant resources that would be devoted to working on the site, and the general low computer literacy of the organisation, the back-end admin screens needed to be as simple as possible — more simple than any out-of-the-box solution could provide. However, they also revealed later in the day that they had in fact made the decision to build their CMS from scratch in the weeks leading up to the competition.

In the Australian camp, the benefits of leveraging an existing CMS failed to eventuate in the way that the team had hoped. Team Australia’s front-end coder, David McDonald, confessed to me that he had spent most of his time overriding the default styles that came with Drupal, rather than investing time in building new pages or styles. The Australians, however, made this call in the first couple of hours, after they had assessed the client’s needs and capabilities.

So I’m interested in hearing from a few readers: how do you make a call on whether a client’s needs are best suited by a CMS, and whether the job needs a custom build?

If you answered CMS, which one? And if you answered custom, would you change your answer if you only had 24 hours to complete the job?

Free book: Jump Start HTML5 Basics

Grab a free copy of one our latest ebooks! Packed with hints and tips on HTML5's most powerful new features.

  • wwb_99

    The statement “I’ve never met a boxed CMS I Like” pretty much summarizes my views on the subject.

    As for the whole 24 hours issue, I am religious about managing deadlines and expectations up front. As for any decision to go to a boxed CMS because of time/resources, that would really depend upon what the requirements were. I would more likely fall back on using some generated scaffolding and patching together 3rd party libraries rather than getting a whole system put together. The Aussie’s comment is very telling–with a fully fledged boxed system, the bulk of your work will be undoing the developer’s initial decisions rather than making your system go the way it should.

  • fsdavis

    After having developed countless CMS solutions from scratch, I’ve been using drupal for the last couple of years. I had pretty much the same philosophy as wwb_99. I’ve found that most existing CMS solutions stink either from a developer’s standpoint or a user’s standpoint, sometimes both.

    But drupal is stable, well-documented, and the most extensible solution I’ve ever seen. I’m not sure what all the “overriding” default styles was about. We generally start new front-end designs from scratch and script them out as drupal themes while using a pre-existing theme for the administration area. Drupal’s hook and module functionality doesn’t require a lot of tweaking to get started.

    Drupal solves some critical problems very well (user management, navigation and design, and forms) so you can get on with developing your solution. We’ve been so successful using drupal as a starting point, that we generally turn down jobs where re-inventing the wheel is a requirement.

  • http://www.tiffanybbrown.com/ webinista

    I probably would have chosen an out-of-the-box CMS, but not Drupal. I would have used WordPress or SilverStripe — two packages with superb flexibility, fairly simple interfaces (IMO), and two with which I’m pretty familiar.

    I guess which is faster depends on what you know best, in addition to what your clients’ needs are.

  • dhtml12345

    CMS Made Simple all the way! Powerful, reliable, flexible. I love it.

  • beenThere

    After spending a year over-riding Joomla’s defaults while trying to build our new site tow work well from a customer pov and from the designers pov.. I’d say go custom-built.

    Seems like every day I have to figure out how to get rid of something Joomla is doing by default.

  • krdr

    I used phpNuke and ExpressionEngine. Sometimes, CMS was gift from Haven, and sometimes it was like came from the Hell. As developer in small European company with some abroad operations, I often build multilingual web sites. In most cases it is Hell. If site is in one language with predictable content, and simple structure, then I’ll go for CMS. Btw, we managed to build very big multilingual online store with EE. 90% of site took 10% of developing. Other 10% took 90%, hurdling with EE’s quirks and other stuff. I even rewrote some of core modules to suit our needs

  • http://www.lowter.com charmedlover

    Every boxed-CMS I have encountered is too complex, for the user and the code itself.

  • Satane

    I used to go with CMS made simple which I found easy to understand for the final user, and very easy for me to modify and add my own code.

    But I’m never satisfied with boxed solutions, I always think it could have been done better. So I eventually wrote my own CMS.

    Nowadays I mostly use my custom made CMS, because I can build and customize websites a lot faster as I know the code very well. But by using it all the time, I guess it makes it a boxed solution itself…

    And I’m never satisfied with boxed solution….

  • The Web Guru

    I use an out of the box hosted solution called EzPz. It does exactly what it says on the tin it is “easy peasy”. It is simple to template, easy to administer and fast. It may not have the excess of features that other CMS’s have, but, that is it’s strength.

  • andreeide

    If the pre built system has a database model suitable for the customers needs, I find this the right path to go.

    I have only tried WordPress, but found it perfect for simple websites with static pages or simple blog functionality.

    For more complex websites I prefer a custom made database model, with a custom made publishing platform on top.

    A combination of pre built and custom system can also work perfectly.

  • Anonymous

    One point though – while we did agree before hand that we would build a editing solution from scratch, we did not pre-plan or design an actual solution in any way (apart from me knowing the PHP framework I was going to use). We had also agreed to use WordPress as our backup plan, so in actual fact, it was all dependent on the scope of the site and the clients needs. It came down to a choice of three possible directions:

    1) Design an admin tool based on a custom data model, allowing all site content to be editable
    2) Use static HTML templates for main section content, with some content regions manageable via a more basic blog editing tool
    3) Use WordPress

    In the second or third hour of the competition I affirmed the decision to roll with a custom designed data model mainly because Zef’s information architecture was so beautiful and precise and the only way to really do justice to it was to roll out a minimalist set of custom editing tools. This decision was mostly influenced by the judging criteria of “maintainability”, wanting to make sure that the entire spread of content could be changed easily by the client, without necessarily needing the ability to customize or modify the architecture of the site itself. Plus the whole team was pushing me to really stretch the boundaries of what I could achieve in such a short time!

    Our original CMS design was actually much more sophisticated, with a tagging/subscription system, but I had to scrap this at 11pm, because it was just too complicated and we needed to move on to other more urgent things. Spending the extra time on this ambitious architecture was almost our downfall, but all of us kept our focus on the design and requirements the whole way through so that everything we implemented reflected the overall message we were trying to communicate.

  • http://www.sitepoint.com/ mattymcg

    Thanks for chiming in Mark (I’m guessing this is Mark?) You guys did a terrific job under pressure!

    Care to share which framework you were using?

  • Ryno

    I’m suprised no one has mentioned Django as a solution to custom built and relatively simple CMSs? Even though I’m not a python developer, I use it for 90% of my PHP client sites just for the auto-admin functionality, it rocks!

  • Anonymous

    Thanks Matt… I’m sorry that you only got to see me having a mental breakdown right at the end when filemtimes were going backwards rather than forwards and nothing made any sense! we were actually quite calm and focused before that point ;) It was heaps of fun anyway, and I hope all the judges enjoyed themselves as much as we did…

    I was using a framework I cobbled together from patterns extracted from various PHP projects I’ve been involved in over the last few years. I focused on designing it from an “HTTP first” perspective, stealing lots of ideas from Rails, Django, web.py, and Java servlets.

  • michael

    I’ve gone both ways with custom code and CMS and have this same argument with my partner on almost every site. She likes the idea of custom solutions and has the skill to program them. I can too but slowly. But there are two vital aspects of using a well supported CMS that haven’t been mentioned.

    Custom coded sites are always alpha releases. The haven’t been load tested and run through the ringer to display all the weird and annoying ways that the code goes screwy.

    A corollary to that is the fact that active projects have a lot of people watching out for various exploits and patching them quickly. I’d much rather follow a Drupal forum and find out that I need an upgrade than find out with a cracked database or defaced pages. Build enough sites and you too will know the joy of malicious hackers.

    So we typically have the discussion, look at the site requirements, then look at the out of box solutions like Drupal, WordPress and CMSMadeSimple, (with modules) choose the closest fit and go. Most of the time we go out of box. The freedom from bug hunting more than makes up for the typically minor misfits.

    We use all three CMSs depending on the complexity of the site and the skill level of the end user. I’m sure that there are other good solutions around but we can only spend so much time evaluating.

  • http://www.davidmcdonald.org davemac

    We chose Drupal because of the pre-built functionality that is available, however because of our limited experience with it we hit some issues, mainly on the front-end side.

    fsdavis asked earlier:
    “… I’m not sure what all the “overriding” default styles was about. We generally start new front-end designs from scratch and script them out as drupal themes while using a pre-existing theme for the administration area.”

    Just to clarify our position a little further, we started with an existing Drupal theme (Zen) and worked back from that, trying to meld it into the design our team came up with. This is where I had issues in overwriting default.css and other Drupal and theme CSS files. Rewriting some of the outputted HTML to suit our needs was difficult sometimes too.

    In retrospect, we should have started from scratch, rather than trying to rework a theme. Our limited experience with Drupal led us to believe we could do this, so I set about basically stripping the theme down to the bare essentials and then applying the design – this caused no end of headaches for me.

    I still think Drupal is a great tool, but maybe we chose the wrong CMS based on our limited experience with it and the time frame. We got the site to a completed state, but there was lots more we all wanted to do until we ran out of time and brain cells.

    I did meet a great group of people and learn a lot more about Drupal, though!

  • Wolf_22

    Each situation varies. My experiences have told me that custom / from-the-ground-up is where EVERYONE should start from, but that is based on clientele or jobs that have little to worry about with deadlines. If you have a team of people who are less than professional making a CMS, out-of-the-box or open source solutions remain most feasible unfortunately. The reason for “unfortunate” is due to the simple fact that these would probably be the sites that will be harrassed / hacked the most, as well as have little originality.

    Regardless, each situation has different demands…

  • wwb_99

    Custom coded sites are always alpha releases. The haven’t been load tested and run through the ringer to display all the weird and annoying ways that the code goes screwy.

    Not really, at least if you have proper testing procedures and resources in place. Nothing we do custom hits the street without some vicious load testing.

    A corollary to that is the fact that active projects have a lot of people watching out for various exploits and patching them quickly. I’d much rather follow a Drupal forum and find out that I need an upgrade than find out with a cracked database or defaced pages. Build enough sites and you too will know the joy of malicious hackers.

    Cracking custom apps is probably harder than cracking the large, popular open source apps for a few reasons. One is that, unless you (or your client) happens to be a target, there is very little payoff with cracking a one-off custom application. Whereas finding a zero-day exploit for WordPress or Joomla will let you deface thousands of sites and/or compromise thousands of servers.

  • Rex Chung

    I was part of the Aussie fullcodepress team that day. On hindsight, I am happy that we went with drupal. I’m sure there’s other CMS out there, but Drupal is one which a few of us had a small amount of experience on. Having said that, none of us had customised drupal before on a commercial level. I learnt a great deal about drupal in 24hrs and the next site would be definitely alot easier.

    Prebuilt CMS like drupal has alot of benefits over building one from scratch in 24hrs. Some of the advantages I can think of are:

    – revisions – ability to save different versions
    – permission system – drupal can create user types easily and customise the permission level for each modules. We had 3 levels of volunteer, content_writer and super administrator. And all the menus can be customised, so its actually simple and easy to use as most users will only see the limited number of links.
    – modules repository – we can easily add ready made modules for different kind of requirements. e.g. volunteers will see a calendar of events where they can opt in.
    – because drupal is quite popular, it is easily for the client to find support and developers if we cannot provide support in the future.
    – drupal is a mature software, it is less likely to have bugs and security issues. I don’t think it would be possible to build a robust solution in 24hrs.

  • James Robertson

    To me, this highlights that if you are going to use a CMS, make sure it’s the right CMS. There are two very different groups that have very different needs:

    Content authors need extremely simple, non-technical interfaces for maintaining content, publishing new pages, etc. They want point-and-click interfaces for everything, and should not need to know any HTML for typical content work.

    Site developers need to be able to work efficiently with the CMS, setting up overall information architecture, page layouts, page designs, etc. They need the CMS to make life easier, and get out of the way.

    These may be conflicting goals. Certainly in the marketplace there are plenty of good developer-focused CMS products that have poor end-user interfaces; there are just as many easy-to-use CMSs that make life a misery for site developers.

    At the end of the day, though, there’s a lot that goes into developing a viable CMS product. I estimated a few weeks ago that it costs $5mil to develop a commercial CMS (or the equivalent time donated to an open source effort).

    As Rex indicated, that’s work relating to versioning, permissions, modules, etc. And does the world really need yet another half-baked CMS? :-)

    So I would always tend to lean towards an out-of-the-box solution. Is Drupal a great CMS? Not really. How well do many of the open source CMS products stack up? Pretty averagely. What about the commercial CMS products? They’re OK, but not guaranteed to be great.

    I definitely think there is a market opportunity for a CMS (open source or otherwise) that is simple, and just “works” for straightforward sites like the ones in this competition. CMSs that don’t need to be wrestled or fought with just to get a simple site up.

    Anyway, just my $0.02,
    James

  • ibroom

    Hi,
    I am a web developer and I primarily use Joomla. There are numerous reasons I do this and here are some of them.

    1. Small and medium sized businesses want solutions which are very flexible and they want it NOW! So I give them what they want with a system which can expand as they expand.
    2. I don’t like locking my clients in. I tell them this, and I think they appreciate it. There are LOTS of developers who have worked with Joomla and if a client hates me at least their web site can continue to be developed by someone else.
    3. I don’t load, stress or even put that much effort into compatibility testing (other than templates) as I know and benefit from over 100,000 web sites already using the system. This is very important, see point 1 as to why.
    4. If I need an e-commerce system or a forum or a wiki, etc. I can quote a sensible amount of my time to implementing the appropriate plug-in for Joomla. Most of the time there is already one available which meets or surpasses my clients requirements. I usually offer clients systems which they can grow in to rather than be dependent on me.

    I used to build custom solutions but I stopped because the cost was too high, the quality too low, and ultimately I can offer my clients better quality and value for money by using a CMS which has the base functionality covered.

    On a final note, coding an authentication system was fun the first time and irritating the second time, and terrible the third. I am not a robot, I like job diversity, therefore I will leverage other people’s excellent systems and spend my expertise doing the tricky things my clients can’t rather than charging them for the boring things I hate.

    Am I right or wrong?

  • http://www.nmwsolutions.com/ jruyle

    Having learned my coding from using CMS, I can understand using a custom system. Although the early development stage is intense, the final custom changes are much easier.

    I do have to admit, I’m surprised no one has even mentioned Joomla! Very easy to use, easy to customize, easy to omit.

  • franzdavid

    I am sitting on the fence with this one. I can see the value in building a custom solution and I have done this for my own and clients projects. But I do spend a lot of time doing work that has already been done before.
    Which is where a system like Drupal comes into play. What is the point in reinventing the wheel? The great thing about Drupal, and other modular systems, is that you just plug in the module you need. So the base system is not super heavy (although it is heavier then a custom job).

    Are custom systems better? Yes they are, if done right. But does the client have the money and time for a custom job? Not always.

    A lot of it comes down to communication. The client may want a site that does ABC in a certain way. Thats fine, and you can make a site that does exactly what they want. But if you explain to the client that you can do ABC in a slightly different way for a fraction of the cost by using a system like Drupal, then they will appreciate your honesty. And that could win you the job over a more expensive developer.

  • death

    If you’ve ever made a CMS for a client from scratch, when a new client comes along, you take your previous cms (which has been improved bit by bit across a half dozen previous clients) and you “custom” hack it for the new client to give them just what they need and nothing else. Estimated Time: 8-14 hours.

  • Jonathan

    We use Drupal extensively, having abandoned our in-house CMS development because it made no financial sense committing 100’s of development hours into a product limited to only our clients. I prefer an out-of-box solution like Drupal over custom because that way the client is not locked in to us. I suspect most custom developers leave their clients high-and-dry after the initial site is delivered. With Drupal we have migrated sites from 4.6 -> 4.7 -> 5.x and soon 6.x. There is an active worldwide community providing continuity and evolution of the platform. Once you understand the Drupal API it’s quite straightforward to deliver powerful and flexible solutions faster than custom code; why repeat developing DB layers, authentication, user profiles, content handling, url aliases, ecommerce etc. when all of those are available out-of-the-box?

  • MrQuestion

    Maybe im a little late with the question, im trying to use Joomla! at the moment but its full of errors. ( Mayb its my own fault )
    I never used any CMS before and wanted to try it, ive got a lil knowledge of php but html etc is no problem for me, its hard for me to install Joomla! without problems and let it work on my own templates what is still not working for me..

    Now my question is if its better to learn HOW to build a custom CMS so you will also understand how to modify templates etc on prebuild CMSs ?
    Im really stuck with this and hope someone can tell me whats the best to learn first because I want to know both.

    Thanks in advance,
    Louis