What to check first in a codebase nobody wants to touch
The original team is gone, changes take a fortnight, and everyone is quietly hoping it holds. A first pass that tells you whether this is a rescue or a rewrite.
Every inherited codebase gets described the same way: it works, but nobody wants to touch it. The people who wrote it have moved on, small changes take a fortnight, and there is an unspoken agreement not to look too closely at one particular directory.
The first question is not "how do we fix this". It is "what am I actually holding". These are the checks that answer it fastest, roughly in the order that a bad answer saves you the most time.
Can you build it from a clean machine?
Clone it fresh and follow the README. Time it.
If a new developer cannot get it running in an afternoon, that number is a tax on every future change, and it is usually the cheapest thing on this list to fix. If nobody can get it running at all — if the only working copy is on one laptop, or the build depends on a service that no longer exists — you have found the real problem, and it is not the code.
Can you deploy it, on purpose, today?
Ask to watch a deploy. Not a description of one.
What you want to know is whether shipping is a decision or an event. If releases require a specific person, a manual step nobody has written down, or a maintenance window, then the team's ability to fix anything is throttled regardless of how good the code is. Teams with a frightening deploy process ship less, so their code gets worse, which makes deploying more frightening.
Check whether you can roll back. Many places cannot, and have not noticed because they have not had to.
What do the tests actually cover?
Coverage percentage is nearly useless here. Look at what is tested instead.
Tests over pure functions and formatting helpers, with none over the checkout flow or the permission model, means the suite passes and tells you nothing about whether the product works. That is worse than no tests, because it is a false sense of a safety net. What you want to find is tests around the parts that would cost money if they broke. If they exist, you can refactor. If they do not, every change is a gamble, and the first work is building somewhere safe to stand.
Where has the data model been worked around?
This is the one that decides rescue versus rewrite.
Look for the signs: a column called type or status holding six meanings, JSON blobs standing in for tables that should exist, the same fact stored in three places with a nightly job reconciling them, a table that everything joins to. Then look for the code that exists purely to compensate — the helper every query goes through, the special cases, the comment that says "do not remove this, it breaks reporting".
Bad code sitting on a sound data model is a refactor, and can be done incrementally while the product keeps running. Sound code on a broken data model is a much larger conversation, because the model is what everything else is shaped around, and you cannot replace it a piece at a time without a migration plan that is itself the project.
What is it running on?
List the runtime, framework and major library versions, and check which are out of support.
This matters less for features and more for the day a security advisory lands against something you cannot upgrade without a rewrite. An end-of-life runtime is a deadline you have already been given, whether or not anyone has read it.
Who understands it?
Run a history of the repository and see whose names are on it, and whether any of them still work there. Then find out what is written down and what is in someone's head.
One person holding the model is a risk you can fix cheaply while they are still available, by having them explain it to someone whose job is to write it down. It gets very expensive the week after they leave.
Reading the result
The pattern is usually clear once these six answers are in front of you. A codebase that builds, deploys, has tests where the money is and a data model that mostly holds is a rescue: unpleasant in places, tractable, and improvable while it keeps earning.
A codebase where the model has been worked around for years, nothing meaningful is tested and deploys are an event is a different decision, and the honest recommendation may be to keep it running under maintenance while a replacement is built alongside it. That is a more expensive answer, which is exactly why it should be reached with evidence rather than a feeling.
Either way, the assessment is worth writing down and worth having whether or not you hire anyone to act on it.