How to Review Code in a Data Room During M&A

Reviewing code in a data room is not the same as auditing a repo you own. You get read-only access through a locked-down viewer, a deadline measured in days, and often no permission to clone, run, or grep at scale. The seller controls what you see. Your job is to find the two or three things that change the price or kill the deal, not to read every file. Start with structure, history, and dependencies. Skip the line-by-line reading that the setting will never let you finish.

What a data room lets you see, and what it hides

Most M&A data rooms expose a snapshot: a zip of the repo, or a hosted viewer with the working tree and maybe the git log. What they hide matters more than what they show. A snapshot strips the commit graph down to what the seller chose to include. It hides CI logs, issue trackers, incident history, and the Slack threads where engineers said the real thing. Assume the version you see is the cleaned version.

So decide up front what you cannot learn here and must ask for in a follow-up request. Production incident history. The list of open security findings. Who actually wrote the core modules and whether they are still employed. A data room review that does not end in a sharp list of follow-up questions was a wasted review.

Read structure and history before you read code

You will not read the codebase. You will read its shape. Open the directory tree and ask where the mass is. A payments company with 80 percent of its lines in an admin panel and 5 percent in the payment engine is telling you something. Look at how many top-level modules there are and how tangled they look from the import graph. This is the same lens I use when scoring a repository you did not write: the map comes before the territory.

If you get the git history, it is the richest signal in the room. Concentration of commits in one departing engineer is a bus factor problem you are buying. Churn stacked on the same few files is where the pain lives, which is exactly what churn versus complexity hotspots surfaces. A history that starts three months ago with one giant initial commit means the real history was thrown away, and you should ask why.

Run the checks the setting allows

Even read-only, you can do more than skim. Pull the dependency manifests and lockfiles. Outdated, unpinned, or abandoned dependencies are a cost you inherit, and the lockfile tells you whether the supply chain has integrity or is a house of cards. Count the tests and, more importantly, read a few to see if they assert anything real. Search for secrets committed in plaintext, which is both a security finding and a discipline signal.

Automated tooling helps here if the seller allows an export. A repo intelligence pass gives you coupling, hotspot, and ownership maps in an afternoon that manual reading would never produce inside the deadline. That is not a replacement for judgment. It is what lets your judgment aim at the right files.

Turn findings into price, not a report

The point of a data room review is a number and a negotiating position, not a beautiful document. Every real finding maps to one of three buckets: remediation cost you will pay after close, risk you want indemnified in the agreement, or a walk-away. A tangled monolith with no tests is not a moral failing. It is six months of engineering time you should price into the acquisition. Say that plainly to the deal team.

Be careful not to overweight what is easy to measure. A clean lint report on a badly architected system is a trap, the kind of thing that makes code metrics mislead the people reading the summary. The decayed architecture is the expensive problem. The lint warnings are noise. Rank by what costs the most to fix, not by what the scanner counted the most of.

The mistakes that waste a data room review

The two failures I see: reading code depth-first until the clock runs out, and trusting the snapshot as the whole truth. Both come from treating this like a normal audit. It is not. You have less access and less time, so you buy leverage with structure, history, and dependencies, and you spend your scarce reading budget on the three modules that carry the business. Everything else is a follow-up question. Ask them before the exclusivity window closes, because after that your leverage is gone.