What we look at in someone else's code in the first two days

A quarter of our work is projects somebody else started. The contractor vanished, the developer left, and the product still runs and the business still needs it. We always begin with an audit, and the first two days follow the same list every time.

The order matters: these checks are fast and tell you the state of a project long before you open any business logic.

1. Does it run locally

It sounds trivial. In our experience roughly a third of projects will not start without help from the original author. No instructions, missing environment variables, a specific Node version documented nowhere.

If the project does not come up within a day, that becomes task one: without local execution, every change goes straight to production.

2. Is there git history, and what does it look like

We read the commit log. Not for tidy messages — for other signals: how many people worked on it, whether there were long dormant stretches, whether there are "fix" commits touching forty files. That last one usually means edits made directly on the server and pushed up afterwards.

3. Are there secrets in the repository

We scan history for passwords, API keys and database connection strings. We find them more often than we would like. If we do, those credentials have to be rotated — git history exists on every machine that ever cloned the project, including those of people who no longer work there.

4. Dependency state

How many packages and how far behind. Minor drift does not worry us. Two things do: major versions more than three years old, and packages the author has deprecated or abandoned. The second is worse — you cannot upgrade, you have to replace.

5. Backups, and whether they have ever been restored

The question is not "are there backups" but "has anyone ever restored one". A backup nobody has tried to restore is not a backup, it is an assumption. We try restoring in the first few days.

6. Where do errors go

If there is no Sentry or equivalent, the company learns about errors from its users. That is the first thing we install, before any fixes: we need to see the real picture, not the one described to us.

On one project this revealed that payments had been failing for 4 % of users for eight months. The client had no idea — those people simply left.

7. The database schema

We dump the schema and read it before the code. A comprehensible table structure almost always means the code will turn out reasonable too. A table with 80 columns named field1, field2 tells you what the business logic will look like.

8. Migrations

Is there a migration mechanism, or was the schema changed by hand through a GUI client. The latter means you cannot reproduce the production database on staging, which blocks any serious development.

9. How deployment happens

Automated deployment from the repository is good. Manual FTP uploads are bad but fixable. The worst answer is "only Sergey knew how to deploy, and he has left".

What comes out of it

After two days we can answer the client's real question: can this be fixed, or is rewriting cheaper. Worth noting that we answer "rewrite" rarely — roughly one case in six. More often the project is in working order and simply had nobody looking after it.