Someone is about to hand you a codebase — through an acquisition, an investment, a supplier handover, or a job title. You have limited time, and the people who wrote it are motivated to look competent.
This is the order I work in, and it's deliberately not the order engineers naturally start with. Nobody's first question should be about code style.
1. Can you build it?
Clone the repository on a clean machine and follow the README. Time it.
If a new engineer cannot get a running build in under an hour without asking someone, that is your headline finding. It means onboarding costs weeks, knowledge lives in people rather than in the repo, and every estimate you're given is optimistic. Everything else in this list is less important than this.
2. Can you release it?
Ask to watch a deploy. Not a description of one — an actual deploy, live.
- How long from merge to production?
- How many humans have to do something?
- What's the rollback, and has it ever been used?
- Who holds the signing keys and store credentials? This one has killed more acquisitions than bad code.
A team that can't release on demand can't fix anything on demand either. That isn't a code-quality problem; it's a business-continuity problem.
3. Where does the money leak?
Put the infrastructure bill next to the user count. Anomalies here are the cheapest wins you'll find, and they tell you how carefully the thing was built.
4. What happens when it breaks?
Ask for the last three incidents. Not a status page — the actual story. If there's no answer, either nothing is monitored or nothing is written down, and both lead to the same finding: you will be surprised, and you won't know why.
Check for crash reporting and error tracking, and whether anyone looks at either. An app running at a 96% crash-free rate with nobody aware of it tells you exactly how the team operates.
A two-day schedule that works
If you genuinely have two days, spend them like this rather than reading code from hour one:
- Morning one — build and release. Clone, build, watch a deploy. Two findings by lunch, and they're usually the two that matter.
- Afternoon one — talk to the engineers. Individually, not as a group. Ask what they'd fix if given a free month. The consistency of the answers tells you as much as the answers.
- Morning two — sample the code. Auth, payments, the biggest file, the test suite, the dependency list. Timeboxed to three hours.
- Afternoon two — access and ownership. Accounts, keys, licences, contracts, data. The boring half, and the half that blocks deals.
Notice code sampling is a quarter of it. That ratio surprises engineers and reassures everyone else, and it is correct.
Questions that get honest answers
How you ask determines what you learn. These work:
- "What would you fix if you had a free month?" People love answering this and it surfaces the real debt in ninety seconds. "Nothing" is itself an answer, and not a good one.
- "What's the part you'd warn a new hire about?" Every codebase has one. Being told about it unprompted is a good sign about the team.
- "When did something last go wrong in production, and what happened?" Tests whether they have incidents and whether they learn from them.
- "What would break if traffic went up 10×?" A good team answers instantly with a specific component. Vagueness means nobody has thought about it.
Avoid "is the code good?" You'll get a defensive answer that tells you nothing, and you'll have spent the goodwill you needed for the useful questions.
5. Now look at the code — but only at these
You will not read a codebase in two days, so don't try. Sample deliberately:
- The authentication and payment paths. Where security bugs and legal exposure live. Read these properly.
- The largest file in the repo. Every codebase has one monster. Its size tells you how long the team has been under pressure without being allowed to pay debt down.
- The test suite — does it run, and does anyone trust it? Coverage percentage is nearly meaningless. "Do you run tests before releasing, and do they ever catch anything?" is the real question.
- Dependency age. A dependency three major versions behind is a scheduled project that nobody has scheduled.
- Commit history. Who actually wrote this? If 80% of commits come from one person who is leaving, you aren't buying a codebase — you're buying a rewrite.
6. The legal layer everyone forgets
- Licence audit. A copyleft licence inside a commercial product is a real problem, always discovered far too late.
- Do they own the code? Contractor agreements without IP assignment are common and expensive.
- Where is personal data, and who can reach it? Under GDPR this becomes your problem the moment you sign.
- Third-party accounts. Store listings, domains, cloud accounts, analytics. Anything registered to a personal email is a hostage situation waiting to happen.
Findings that should change the price
Most of what an audit turns up is normal — every real codebase carries debt. These are the ones that are genuinely material:
- Nobody currently employed can deploy it.
- Signing keys, store accounts or domains aren't controlled by the company.
- The IP chain is broken.
- One departing person wrote the majority of it.
- A dependency or platform requirement forces a rewrite within twelve months.
Only one of those is about code. Technical due diligence is mostly not technical — it's about whether the knowledge, the access and the ownership actually transfer with the deal.
What good looks like
You'll know within an hour. Good teams hand you a repository that builds, a document explaining why things are the way they are, and an engineer who volunteers the weak spots before you find them. That last one is the strongest signal there is: people who tell you where the bodies are buried are people who have been thinking about the bodies.
If you'd rather not run this yourself, it's exactly what a product audit is for — a fixed hour, an outside opinion, and no incentive to be polite about the answer.