Software Due Diligence: What Buyers Really Check

When someone offers to buy your company, or lead your round, the number on the term sheet is a starting position, not a promise. What decides whether it holds is the fortnight that follows: an independent engineer, hired by the other side, goes through your codebase, your infrastructure, and your team, and writes a report that either confirms the price or quietly knocks a chunk off it. That process is technical due diligence, and most founders meet it for the first time at the worst possible moment, with a signed intent to buy and no time to fix anything.

It is worth understanding before you are in the room. Technical due diligence is not a code beauty contest. The buyer is not looking for elegant abstractions. They are pricing risk: how much of what they are paying for is real and durable, and how much is one resignation or one outage away from disappearing. Here is what they look at, what makes them nervous, and what you can do about it on either side of the table.

What due diligence is actually measuring

Every finding in a technical due diligence report rolls up to one question: how safe is this asset to own? A buyer paying eight figures for software wants to know it will still work, still scale, and still be maintainable after the people who wrote it have cashed out and moved on. So the review is less about today's features and more about tomorrow's liabilities.

That framing explains why the same codebase can pass one review and fail another. A pre-seed investor and a strategic acquirer are pricing different risks. The first cares whether you can ship fast enough to find product-market fit; the second cares whether the thing they are absorbing will blow up in production two quarters after close.

The seven areas a reviewer digs into

A serious review covers roughly the same ground every time:

• Architecture and scalability. Will the system survive 10x the load without a rewrite? Reviewers read the architecture, not the marketing. Monolith or microservices matters far less than whether the design was chosen on purpose.
• Code quality and delivery. Test coverage on the paths that make money, a reproducible build, a real CI/CD pipeline. Not perfection, but evidence the team can change the software safely.
• Team and key-person risk. The dreaded "bus factor of one": a single engineer who holds the whole system in their head and nowhere else. This is the finding that scares acquirers most, because you cannot buy it, only retain it.
• Security and compliance. Secrets committed to the repo, unpatched dependencies, how customer data is handled versus what the privacy policy claims.
• IP and open-source licensing. GPL or AGPL code linked into a proprietary product is a genuine deal-repricer, because it can force you to open-source what you are selling.
• Data and AI exposure. Where data lives, who can reach it, and whether customer data has quietly ended up training a model it should not.
• Roadmap credibility. Does the plan match the money? A roadmap whose costs contradict the financial model is a red flag in both directions.

The findings that reprice a deal

Most reports are undramatic. The ones that move the number tend to be the same handful every time: a single engineer who holds everything, no reproducible deployment, restrictive open-source licenses tangled into the core, customer data used in ways the privacy policy does not cover, secrets in the repository, no tests around revenue-critical paths, and a roadmap that cannot be built for the budget claimed.

None of these are exotic. That is the point. They are cheap to fix with six months of notice and expensive to explain with six days, because by then the finding is not a task, it is leverage in a negotiation you are already losing.

What it costs and how long it takes

An independent technical due diligence engagement typically runs between 15,000 and 60,000 dollars, scaling with deal size and system complexity, and takes one to three weeks. The buyer pays for it, but you pay for what it finds. On a seven-figure deal, a single serious finding can cost you more in a price adjustment than the entire review cost the other side.

If you are the one being reviewed

The founders who come through cleanly did the boring work early. They wrote down the architecture, removed the secrets from git, ran a license scan, made sure more than one person could deploy, and made the technical story match the financial one. Much of this overlaps with what a fractional CTO is for: having a named technical leader who can answer for the codebase is itself reassurance to a buyer, and its absence is a red flag.

The reflex to resist is treating diligence as an exam to cram for. It is closer to an inspection of a house you already live in. You cannot fake a foundation in a weekend, and the whole exercise is designed by people who know that.

If you are the one buying

On the other side, the value of diligence is not the pass or fail. It is the punch list. A good report tells you what you are really buying, what it will cost to make it safe, and which findings are worth walking away over versus repricing around. The same discipline that reveals whether to buy a company reveals whether to build or buy software in the first place: you are pricing the true cost of ownership, not the sticker.

We run technical due diligence for both sides, an independent read of the code, the risk, and the roadmap before the money moves. If you are heading into a deal, on either end, tell us where you are and we will tell you what a reviewer is going to find before they do.