A developer went quiet. An agency delivered something that almost works. A contractor left and nobody can deploy. However you got here, you are about to become responsible for software you did not write, and the decision to accept that is usually made with far less information than it deserves.
These are the five things we check first. Each takes under an hour, none of them requires deep familiarity with the code, and any one of them can change the answer.
1. Does it build on a clean machine?
Take a laptop that has never seen the project. Clone the repository. Follow the README. Does the thing build and run?
Surprisingly often, no. And a project that only builds on one departed person’s machine is not a codebase, it is an artefact of a machine. The gap between those two is measured in weeks of archaeology: an undocumented environment variable, a package pinned to a private registry nobody has credentials for, a database seeded by hand two years ago.
This is the single most predictive check. Software that builds cleanly from a fresh clone is usually software that was maintained. Software that does not, usually is not — and the state of the build is a better signal than the state of the code.
2. Where are the secrets?
API keys, database passwords, payment credentials, signing certificates. There are three answers and they rank badly.
- In a managed secret store. Good. Someone was thinking.
- In environment variables set by hand on the server. Workable, and undocumented in practice, so plan to rediscover them.
- Committed to the repository. Assume every one of them is compromised and rotate all of them, including in the history. Even a private repository has been on laptops you cannot account for.
Search the history, not just the current files. Secrets get removed from the tip and stay in the log forever.
3. What is the deploy and rollback story?
Ask how a change gets to production, and then ask how it gets taken back out.
The second question is the one that matters. Plenty of projects can deploy — somebody drags files, or runs a script, or pushes a branch. Far fewer can undo it. If the answer to “how do we roll back” is “we fix forward”, you do not have a rollback, you have an outage of unbounded length every time something goes wrong at a bad hour.
Also ask whether there is a staging environment and whether it matches production. A staging environment three deploys behind is worse than none, because it produces confident answers that are wrong.
4. Who owns the accounts?
Not the code — the accounts. The domain registrar, the DNS, the cloud provider, the app store listings, the source control organisation, the payment gateway, the transactional email service.
This is administrative rather than technical, which is exactly why it gets skipped, and it is the part that becomes genuinely difficult once a relationship has ended badly. Do it today even if you never hire anybody. We wrote separately about who owns your cloud account and what to do if the answer is not you.
5. What happens when a test fails?
Not “is there test coverage” — the percentage tells you very little. Run the suite. Does it pass? Does it run automatically on a pull request? And critically: if it fails, does anything stop the change from shipping?
A test suite that has been red for eight months is worse than no tests, because everyone has learned to ignore the signal. Restoring trust in it costs more than writing it did.
One more, if the previous developer is still reachable
An hour of handover conversation is worth several days of reading code, and it is the cheapest hour in the whole project. Ask three things: what were you in the middle of, what would you fix first, and what is the part you are worried about.
That third question is the valuable one. Every developer knows where the bodies are, and most will tell you if the conversation is not adversarial. Pay for the hour if you need to. We have never regretted asking for it, and we have regretted skipping it.
While you are at it, check the dependency state: how far behind are the major libraries, and is anything abandoned? A framework two major versions behind is a scheduled project nobody has scheduled, and an unmaintained dependency at the centre of the system is a rewrite waiting for a security advisory to trigger it.
What the answers actually tell you
Notice that none of these five is about code quality. That is deliberate. Code quality is subjective, slow to assess and easy to argue about. These five are objective, fast, and they measure whether the project was operated — which predicts the cost of taking it on far better than how the code reads.
A tidy codebase nobody can deploy is a worse inheritance than a scruffy one that builds, tests and rolls back cleanly. The scruffy one you can change safely on day two.
When the answer is to start over
Sometimes it is, and it is worth saying that a rebuild is the smaller and less profitable engagement of the two, so a firm recommending one is not doing it for the money.
More often the honest answer is in between: the data model is sound and the interface is not, or the app is fine and the infrastructure underneath it is the problem. That is a much better place to start than either extreme, and you only find it by looking. We do this as a fixed-price audit, typically $2,000 to $5,000, and the written assessment is yours whatever you do next — including taking it to another firm.
