Our Blog

Taking Over Existing Web Projects

By Heshy Friedman

Anger businessman with blue screen errorI am often asked to take over an existing website project, and in most cases I will turn down the offer. I have learned from experience the troubles that often come about from accepting such projects. Almost all of the projects I work on were created by my company, and my staff and I are familiar with the coding and structure. Maintenance and updates are therefore fairly straightforward since everything is organized, the code is clean, and the functionality fully operational.

When taking over a project from an existing developer, I don’t have this advantage. Even if the coding is clean (which it usually isn’t), I may not be able to easily locate an include file or script control without having to dig deep into the codes.

When asked to take over a project done by a previous developer, there is usually a red flag. Why did the customer not have their original developer work on the project? In almost all the cases I have seen, there was a fallout between the developer and the customer. The fallout can be from the customer’s end, where the customer was difficult to work with or didn’t pay. The fallout could have also have been with the previous developer, where they make things difficult for the project to be taken over by intentionally hiding certain files, encrypting code, or failing to provide source files. In either of these circumstances, I don’t want to take upon myself all this extra baggage.

Another common reason I am asked to take over a project is when the previous developer is overseas, and the customer has too much difficulty communicating properly. The frustration that ensues necessitates the customer finding someone local to take over. While there are overseas developers who can do a good, clean job, many seem to be lacking in organizational skill, and I have found these projects difficult to take over as well.

Aside from poor coding and organization, a project done by a previous developer can also have been done in multiple stages by different developers, resulting in a jargon of extra files and unused or unknown script libraries. In those circumstances where I reluctantly took over an existing project, I noticed that even when I fix or update one thing, another thing breaks.

When I am asked to do work or take over an existing project, the first thing I ask for some background. My main question is: “Why aren’t you using your previous developer?” The answer usually gives me insight to the situation. I’ll then usually ask to take a look “under the hood” to see what is going in. I’ll request FTP access to inspect the file structure and coding, hosting control panel access to take a look at the data structure, and a CMS (Content Management System) login to inspect if the system is using a CMS and the type/version/plugins that are present.

Often, a client isn’t able to provide the above information. This effectively locks me out, and won’t allow me to inspect the website. This generally indicates they are having difficulty getting material from the previous developer, which will indicate further problems that I don’t want to deal with.

If I am provided with proper login credentials, I’ll take a good look at the file, data, and coding structure. If they are using a CMS, I’ll look at the version, plugins, and customizations. I’ll only agree to work on the site if the code is clean and the structure not too complex. If its CMS system like WordPress, I’ll only work on it if it’s a stable installation, doesn’t have excessive plugins, and is a relatively recent version.

In cases where I won’t be able to work on an existing project, I usually suggest a makeover or recoding. In the long run, if the website is clean and stays updated, it will save more time, money, and minimize headaches.


Copyright © 2022 Azurite Marketing Group, all rights reserved.