Start "From Scratch"

When getting quotes for improvements to an existing project, clients are often faced with the suggestion of building it from scratch. This is usually with good intentions but can easily raise questions as to exactly where your budget is going and whether this is the best solution for the requirements. Typical good reasons include:

• The website/app is five years old or more. A lot of frameworks have a Long-term Support (LTS) release for this time period where the framework receives security updates. Depending on when your project was released, this time period is often shorter just because it was launched part-way through the LTS schedule.
• The current codebase has been dubiously maintained. If features and fixes have been tacked on, it near-always leads to a maintenance nightmare. This is part of “technical debt” and deserves it's own in-depth topic.
• The current website has been built with alpha or beta releases of libraries and supported releases are not backwards compatible. This makes it a difficult stack to progress with, and usually requires significant maintenance work to adjust the libraries to their stable versions without breaking features.

Coding is easy, but developing a full-featured, maintainable web application is a very involved task. A new developer will have to work out the current codebase and it is rare for code to be properly documented (if at all). Due the the industry’s low barrier of entry, it is extremely common for people to ignore industry best-practices and focus on impressing the client with speed of implementation. On Wordpress this can mean customisations have been done in core files or outside of child-themes which breaks updates. On a bespoke web application, it usually means chunks of code have been put in the wrong layers of the application, or the features of the framework have not been fully realised.

When a new developer takes on an existing codebase, they are inheriting the issues of the previous developer. This is an unknown quantity and mostly includes problems which aren’t blatant until far into development. This is a frustrating problem, and why a lot of developers would rather re-build it with a fresh perspective. The developer needs to weigh-up whether migrating the existing data and processes is easier/quicker than fixing what's already there (solving the existing technical debt).

 

If you are faced with this suggestion, bear the following questions in mind:

What are your requirements?

If you are updating the design of your website, and your current site is reasonably new (two years old) then depending on the platform, you should really probe why the it needs to be built from scratch and get a second opinion. A two year old Wordpress website should be auto-updating itself without issues negating the security concerns of out-of-date software. This does depends on the competency of the previous developer.

If you are introducing entirely new processes to a large web application, or overhauling the existing processes, then this is very dependent on the existing application, it's age, and existing difficulties.

 

What are the technical problems with your current platform?

If you have to force the server to use a specific version of PHP, then the suggestion to re-write is with good intentions. Frameworks, libraries, and also PHP itself require security updates. A web application would be built with a specific version in mind (the latest stable release, hopefully) which means the lifespan of a project release is restricted to this time. It will work for longer than this, but at the risk of increasing security breach. You are putting your customers at risk by ignoring these security concerns which can easily be more costly than solving them.

 

How was the development process on your existing platform?

If it was a frustrating experience of bringing up missing features and bugs, getting told they’re fixed, and then finding them again or others amongst reluctant communication, it would seem the previous developer tried solving the problem in the quickest way possible with little consideration as to what the change will do throughout the system. It's solvable, but at a potentially large cost.

 

If you need a second opinion, don't be afraid of giving a professional developer access to the code. We like to build solutions, not rip them off, and it's extremely unlikely to find an industry-secret algorithm which can be plugged into other projects - if the temptation was even there in the first place.