Web developers and web development companies frequently start each project as if they only things that need to be built require merely different types of nails, and luckily they have a hammer. In fact, they often call themselves “Drupal developers” or “Ruby on Rails developers” rather than Web developers (or software engineers). The opposite also happens, where someone will approach each project as a custom, ground-up web development project. Wars inevitably break out over what platform is “best” for web development. Purists slag framework devs as lazy and imprecise, framework devs slag CMS developers the same way and purists as wheel-reinventors, and CMS devs slag the others as wheel-reinventors and one another as using an “inferior” CMS.

The best developers I know may have favorite tools, but they either put them aside when they’re the wrong tool or pass on inappropriate jobs in favor of projects that match their preferred development niche. Others simply choose the best tool for the task at hand…but that choice can be the first point of blank page syndrome. What follows are questions to ask yourself and how the answers can influence your choice.

What does the client expect?

Every project has a client. Even if that client is yourself or your boss, let alone someone who is paying you for a bespoke web application. Sometimes they have particular ideas, for good or ill. You can try to argue the choice if you think it’s wrong, but ultimately the person paying will have to approve your choice. Obviously if you’re adding on to a Drupal website, you have to make a pretty strong argument that Zend Framework is the right choice. (Though I’ve seen it done.) In the nonprofit sector, for example, there’s a huge preference in favor of Drupal for anything larger than a basic site or blog. A previous company I worked for tried to argue for a different solution, but ultimately had to deliver what clients wanted as many dropped non-Drupal proposals immediately.

What is the legacy technology stack?

It’s been a decade since the average web development project was “helping an organization finally get on the web.” Even new projects in existing organizations are often project-specific websites in addition to the main organizational site. Sometimes organizations have a large infrastructure dedicated to serving other sites. While in general I’m not a fan of people hosting their own sites and often throw out the sunk cost fallacy in arguments, sometimes it’s easier to reuse existing equipment and experience than introduce a new technology stack. So if an organization has a ton of ExpressionEngine sites, asking them to host a Drupal site may not end well if they’re not familiar with keeping Drupal up to date or staff need a lot of handholding to use a new system.

What does the end product mostly do?

Even if the excitement is around a small application on the site, if the bulk of the requested functionality revolves around managing web pages, articles, and comments, then starting with a CMS may be the responsible thing to do. While every CMS entails design tradeoffs and limitations that often drive experienced developers nuts, I’d rather focus my development effort on getting that one web application right and adapting it to the CMS’s module structure and API than rebuilding page, menu, login, admin, and comment functionality again.

What will the application do over time?

Small organization sites may live forever as a basic set of rarely-updated pages. Most restaurant pages only need to update menus and maybe an events calendar. Intranet applications will tend to get added on to and fixed over time but never have a vast number of users. And that social networking site may become Facebook.

While lots of startups jumped on the Ruby on Rails bandwagon after Twitter took off, Twitter ended up rewriting most of their site as they scaled. The tradeoff was a quick minimum viable product versus a platform they could easily grow as time went on, and there was a period in which had another service arisen on a more reliable stack, we’d remember Twitter the way we remember Friendster. At mojoLive, we looked seriously at Zend Framework since it was built to have any individual component thrown out for a custom replacement as was needed for scaling, but ultimately it didn’t help us do enough of the hard things easily and would require a significant learning curve to build something we knew was going to be thrown away. Building a custom app based on some code Eli had lying around with a minimal MVC layer didn’t slow us down appreciably over picking up a new framework.

Startups and large enterprise applications also have developers working on them all the time, unlike small organization sites. In the latter case, a well-known CMS is going to be a lot easier than a custom-built CMS for someone to come along and update when you’ve gone on to bigger and better things.

What do you know?

Unless you’re doing a project specifically to learn a technology (and it’s either personal or the client has approved you taking on something you don’t already know because they’re awesome, desperate, or you gave them a big discount), it’s rarely a good idea to start with something you don’t know. Even if you know PHP inside and out, Zend Framework and Drupal have layers of best practices specific to those environments that take time to learn. And jumping from an object-oriented or imperative language to a functional language is…challenging, to say the least.

When is the project due? What’s the budget?

There’s no point in building a new CMS that’s going to take over the world just to churn out a 3-page site due end of the week. The less time you have, the more you’re going to want built for you. Similarly, you’re going to want to stick closer to what you know.

TL; DR

There is, unfortunately, a lot of overlap in the capabilities of systems. Obviously you can ground-up write any app in existence, if you have enough time and budget. (And skill and experience and…) That being said, you can make Drupal into a 300+ mini site system with overlapping permissions, 12,000+ shared users, and single signon with Salesforce. It wasn’t my first choice, but the mix of familiarity, budget, and client expectations led me there. That being said, it was a huge pain and the gains of the CMS components were probably overwhelmed by trying to shove a very idiosyncratic enterprise-level set of requirements onto a CMS whose sweet spot is rapidly building middling complexity content management sites with community features.

In general, though, sites that primarily content belong to CMSes, sites that are primarily web apps with tighter deadlines or without huge growth requirements are better off with frameworks, and sites that are going to be constantly developed and scale rapidly are likely best ground-up. You can find exceptions to all of these, and there are clever people who’ve built simple ground-up CMS apps and made WordPress run massively complex sites, but that rule of thumb should keep your next project from being a cautionary tale of trying to hammer in screws.