A Repo Due Diligence Checklist Before You Acquire

Before you acquire a company, its codebase is a liability you are agreeing to own, and most deals never look at it until after the wire clears. That is backward. The repo tells you things the pitch deck never will: whether the product can actually be extended, whether one person leaving takes the knowledge with them, and whether you are buying an asset or a rewrite wearing a maintenance costume. Here is the nine-point checklist I run before I commit to owning any codebase.

Can the product actually be changed?

The first question is not is the code pretty. It is can I ship the roadmap on top of this. Trace two or three real feature paths end to end and estimate what adding a genuinely new capability would cost. If simple changes require touching a dozen files and a week of testing, you are buying friction, and that friction is priced into every future release forever. I walk through this trace-the-paths method in how to audit a codebase you inherited.

Is the data model sane?

Pull the schema and read it. The database is the truest document in the deal. Missing foreign keys, columns named temp and data2, a single table with sixty columns: these are the fossil record of every corner the team cut under pressure. A messy data model is the hardest thing to fix after acquisition because everything sits on top of it. Weight this check heavily.

Where is the churn concentrated?

Run a churn analysis on the git history. A small set of files usually absorbs most of the changes and most of the bugs. That set is your real liability, and its quality matters far more than the average across the repo. High churn plus high complexity in the same files is the single clearest predictor of ongoing pain. ReformCode surfaces this in minutes, which is exactly what you want when a deal is on a clock.

Do the tests actually test?

Do not trust the coverage badge. Open the tests, confirm they assert real behavior, then break something on purpose and see if they catch it. A suite that passes while the code is broken is worse than no suite, because it will sell your integration team false confidence for months. I break down why coverage misleads in code quality score vs test coverage.

How much is key-person knowledge?

Look at the commit history by author. If one person wrote 80 percent of the critical code and that person is not part of the deal, you are buying a car with the manual locked in someone else's head. Undocumented, single-author systems are a real valuation risk. Ask directly who understands the hard parts and whether they are staying.

What is the dependency and security posture?

Check the dependencies for abandoned packages, years-old versions, and known vulnerabilities. Outdated dependencies are deferred work with interest, and some of them are security incidents waiting for a date. This is also where you find licenses that could poison a commercial product. It ties directly into whether the code can even carry proper audit trails if the buyer needs them.

Is there any documentation that matches reality?

Skim whatever docs exist and spot-check them against the code. Out-of-date documentation is common and forgivable. Documentation that actively lies about how the system works is a signal that the team stopped caring, and that neglect usually shows up everywhere else too.

What does the deploy and infra story look like?

Find out how the thing actually ships. A manual, undocumented deploy that only one person can run is an operational hostage situation. You want to know before you own it whether you can deploy on day one or whether you are inheriting a ritual nobody wrote down.

What is the true cost to bring it up to standard?

End the checklist with a number, not a feeling. Add up the top three risks and estimate what each costs to fix. That figure is your real acquisition price, and it belongs in the negotiation, not in a surprise three months later. Sometimes the code is fine and the deal is a bargain. Sometimes the cleanup costs more than the company, and the checklist just saved you from finding out the expensive way.

Run it before the wire, not after

None of these checks are exotic. What is rare is running them before the money moves, when the findings can still change the price or kill the deal. A repo audit during diligence is the cheapest insurance in the whole transaction. Skip it and you discover the liabilities as outages, key departures, and blown timelines after you already own them. Run the checklist and you buy with your eyes open.