← All articles

Taking over a codebase from another developer: what we check first

The audit we run before quoting on inherited software.

Roughly a third of our new projects start with code someone else wrote. Sometimes the previous developer moved on; sometimes the relationship ended badly. Either way, the first job is to find out what you actually have. This is the audit we run.

Access and ownership

Before anything technical: do you have admin access to the repository, hosting, domain registrar, database and any third-party services? A surprising number of businesses discover their domain or server is in a former contractor’s personal account. We fix this first, because nothing else matters until it is fixed.

Can it be built from scratch?

We take a fresh copy of the code and try to run it on a clean machine. If it only works on the old developer’s laptop or a server nobody can reproduce, that is the biggest risk in the project and it goes at the top of the report.

Dependencies and security

What frameworks and libraries are in use, how far out of date they are, and whether any have known vulnerabilities. Old PHP or Node versions are common and usually fixable; abandoned frameworks are harder.

Data

Is there a backup? When was it last tested by actually restoring it? Is customer data encrypted at rest? The answer to the second question is almost always no.

The honest verdict

The audit ends with one of three recommendations: keep and maintain, refactor in place, or rebuild. We put a price on each. Most inherited codebases are a “refactor in place” — rarely as bad as the client fears, rarely as good as they hoped.

Audits take one to two weeks and are quoted separately from any follow-on work, so you can take the report elsewhere if you want to.

Have a project like this?

Tell us about it. We reply within one business day.

Get a quote