Rebuild or Reuse?

The kind words above were recently shared with us by a client after we launched their newly redesigned website. Beyond simply building something that works extremely well, when a client is additionally upbeat about our process and personal interactions, we view that as a real success, and truly value such feedback.

We discussed this project around the office, and began assembling a case study. Except that—as you'll find below—this isn't so much a case study as it is a cost-benefit analysis of an ExpressionEngine project, and there's a reason for that.

Typically, a case study will highlight the most noteworthy aspects of its subject—and amidst this project there were many—but as our team examined the initial outline for such a study, we arrived at the fact that in this particular scenario, portions of the site's robust feature set—and the ExpressionEngine channels and custom fields with which said code interacts—were actually carried over more or less untouched from the site's previous iteration.

This shifted the conversation in an interesting direction, and of course raised the question: why?

When faced with a complete website redesign, we start with an evaluation of the current site and assess the goals of the overhaul. More often than not, this results in a full rebuild—the front-end code, the data structure within the CMS, the templates, etc.—because, in the long run, it’s generally the most cost-effective solution. A full rebuild provides a fantastic opportunity to tackle the types of cleanup and organization discussed in my last post—keeping things tidy and simple for content administrators, and easier to maintain for developers—as well as to resolve any bugs or pain points that may be present within the current implementation.

However, as I've said before, there are exceptions to every "rule," so there are certainly arguments to be made for retaining and reusing existing code in certain circumstances. Working with the client’s internal design team, our collective journey to those final weeks of actual development was a long road that included a number of meetings—both in person and via Skype—to outline functional requirements, budget, and so forth. A fairly large site gravitating toward its first responsive experience, the client consulted with our team for advice on a number of design iterations throughout the process to evaluate and discuss ExpressionEngine’s deep integration with their supplementary internal business systems.

Based on our conversations about the client’s objectives and priorities, we put together a development plan that considered the best possible return on investment for their budget. We at Foster Made are always vigilant in our attempts to make intelligent and efficient decisions in order to provide the greatest possible value to our clients, so in order to preserve as much of the existing functionality as possible, we decided to rebuild this website within a copy of itself—adding, replacing, or refactoring each area of the site one by one, and cleaning out the unnecessary remainders after our new solutions had been tested and confirmed complete.

Ultimately, the bulk of the redesign did consist of all-new code and a fresh CMS interface. As for the carryover—largely related to search results, fine-tuned content filtering, and member-related actions tied to the client's external resources—as the adage goes, "If it ain't broke, don't fix it." These features were already working, stable, and unlikely to require any additional development effort in the foreseeable future. Investing the time required to convert the site's existing treatments into custom ExpressionEngine add-ons would not have presented any visible benefit to the client at that time; whereas reusing the existing components provided a prompt and logical solution.

In the end, we feel that we made vast, tangible improvements for our client and their users by remaining budget-conscious and focusing our efforts where they were most beneficial. To our delight, the client agrees: