Technical due diligence on a software business

Financial due diligence tells you what a software business has earned; technical due diligence tells you whether it can keep earning that under new ownership, and whether it is carrying risks a financial statement would never show. Skipping the technical side because the revenue numbers look good is one of the more expensive mistakes a software buyer can make, because code and data problems tend to surface after closing, not before.

Financial due diligence on a software business

Start with normalized financial statements over several years, reconciled to actual bank and payment-processor records, and break revenue down between recurring and one-time so you can see what the business would look like if the one-time work stopped tomorrow. Confirm what has been added back to reported profit and whether each add-back genuinely would not recur under new ownership, rather than accepting the seller’s list without checking it.

Technical and code diligence

A technical review, ideally by someone independent of you and the seller, should assess code quality, how well the codebase is documented, what third-party services and dependencies the product relies on, and whether the architecture can reasonably scale or is held together by workarounds only the founder understands. Ask directly whether source code is held in escrow or otherwise protected in a way that gives you access if something goes wrong before closing, and confirm exactly what you are receiving and when.

Security, data handling and privacy diligence

Review how the business collects, stores and secures customer and user data, including whether it has experienced any past security incidents and how those were handled, since a software business that processes personal information is subject to federal privacy law and, in some cases, additional obligations depending on the data and customers involved. A security review covering access controls, data storage practices and incident history belongs alongside the code review, not as an afterthought once the deal is otherwise agreed.

Customer concentration and churn

Look closely at how revenue is distributed across customers, how quickly the business loses existing customers, and whether any single customer relationship is large enough that losing it would materially change the business you are buying. A shrinking customer base disguised by a few large new contracts is a common pattern worth specifically checking for, because the aggregate revenue number alone will not reveal it.

Key-person and founder dependence

Map out who actually holds critical knowledge — architecture decisions, key customer relationships, credentials and access to essential systems — and confirm how much of that is documented versus living only in one or two people’s heads. A software business built almost entirely around one technical founder’s undocumented knowledge is a materially riskier purchase than one where that knowledge has been spread across a team and written down, even if the two businesses look identical on a financial statement.

How long technical diligence takes

Technical and data diligence on a software business can take real time, particularly for a larger or more complex codebase, and rushing it to meet a closing deadline is one of the more common ways buyers miss something significant. Bring in independent technical, security and legal expertise rather than relying solely on what the seller’s team represents, and build enough time into the transaction timeline for that review to actually be thorough.

Legal, contract and open-source licence diligence

Alongside code quality, review the legal status of what the code actually contains: whether open-source components are used under licences that impose obligations on how the resulting product can be distributed or modified, and whether any of those obligations could affect how the buyer intends to operate the business after closing. Some open-source licences require sharing modifications or attributing the original source, and a business that unknowingly depends on a more restrictive licence than expected can face real limitations post-purchase, so this is worth a specific, dedicated check rather than an assumption that all open-source use is equivalent. Review customer, vendor and platform contracts for the same assignment and change-of-control issues covered in general legal due diligence, since a technically excellent product still carries risk if the contracts underneath it cannot be assigned to a new owner cleanly. A companion guide covers intellectual property and contract transfers in more depth. None of these checks are optional extras layered on top of the technical review — an otherwise well-built product can still be a poor purchase if the legal foundation underneath it is unclear, and untangling it after closing is almost always harder than catching it beforehand.