What the Term Sheet Doesn't Show You: Auditing Custom Software Before an Acquisition

In most acquisitions, financial diligence is forensic and legal diligence is exhaustive. Technical diligence, by contrast, is often a single call with the target's engineering leadership and a glance at an architecture diagram. The asymmetry is remarkable given how frequently the purchase price depends on a claim about software: the proprietary platform, the differentiated data model, the automation engine that supposedly runs the business.

Custom software appears in a deal in two forms. On the balance sheet it is capitalized development, an asset with a remaining useful life. In the pitch it is competitive advantage. Neither framing survives contact with a codebase that cannot be built reproducibly, depends on one engineer who has already given notice, or contains a copyleft dependency that obliges the acquirer to publish source.

Why code gets audited last

Technical review is deferred for understandable reasons. It requires specialist skills that deal teams rarely hold in-house, it resists the tidy summary formats that investment committees prefer, and it can feel adversarial in a relationship built on optimism. Sellers, for their part, have little incentive to volunteer that the deployment process lives in one person's shell history. The result is that technical risk surfaces after closing, when it has a name, a budget line, and no negotiating leverage attached.

A pre-close audit framework

Inventory and architecture. Produce a complete list of applications, services, scheduled jobs, and integrations, with a named owner for each and a diagram verified against reality rather than against documentation. Confirm what is actually in production, including the shadow scripts that everyone relies on and no one maintains.

Build and deployment health. Ask for a clean-environment build performed in front of the auditors. If the software cannot be built and shipped without the presence of a specific individual, that is a finding, not an inconvenience.

Maintainability assessment. Examine test coverage claims against actual tests, measure complexity in the modules carrying the most business logic, and review the age and volume of unresolved defects. Look at recent commit history and ask why the busiest files are the busiest.

Licensing and intellectual property. Request a software bill of materials and verify it. Check for copyleft licenses in distributed components, commercial library terms that do not transfer on change of control, and contractor agreements that failed to assign intellectual property to the target entity. This is the category most likely to produce a legal surprise after closing.

Data dependencies and third parties. Map every external service, API, and data feed. Confirm contract terms, transferability, rate limits, data residency obligations, and what happens to personal data already held. Identify any dependency on a platform operated by the target's largest customer, since that arrangement frequently does not survive the deal.

Security posture. Review vulnerability management, secret handling, access control, and the last two years of incident history. A pattern of unremediated high-severity findings is a statement about engineering culture, not about tooling.

Key-person exposure. Identify the individuals without whom core systems cannot be operated. Review retention agreements, equity vesting, and whether documentation exists that would let a new engineer take over within a quarter.

Operating economics. Model cloud and infrastructure spend per transaction, not per month. Look for scaling cliffs, committed-use agreements, and licensing arrangements that become materially more expensive once volume grows.

Roadmap feasibility. Compare the plan in the investment thesis with the velocity the team has actually demonstrated. Diligence routinely assumes the acquirer's engineering resources will accelerate delivery; the audit should test whether the architecture permits it.

Red flags that predict a rebuild

Certain findings recur so reliably that they should adjust expectations immediately. A deployment process with no reproducible path and no environment parity. A single maintainer for the core service, particularly one without a retention package. Undocumented customizations layered on a vendor product that will require upgrading. Integration code written against a single customer's idiosyncratic systems and generalized only in the sales narrative. Test suites that run but assert almost nothing. A data model shaped around a business unit the acquirer intends to divest.

Individually, each is manageable. Together, they describe a system that will be replaced rather than extended, and the replacement belongs in the deal model.

Turning findings into terms

Technical diligence is only useful if it changes something. Findings can be expressed as a purchase price adjustment, a holdback or escrow released against a defined remediation plan, a specific indemnity covering licensing or IP exposure, revised earnout metrics that do not reward delivery the architecture cannot support, or retention packages for the engineers who hold the operational knowledge. A transition services agreement is often the cheapest insurance available, provided it is negotiated while leverage still exists.

The first hundred days

Assuming the deal closes, a sequenced remediation plan matters more than a comprehensive one. Stabilize the build and deployment path first, because nothing else can be verified until it is repeatable. Then secure the key people, close the highest-severity security findings, and document the integrations that carry revenue. Only after that does it make sense to debate the roadmap the investment committee approved.

Technical due diligence is not an argument against acquisition. It is the mechanism by which an acquirer learns whether it is buying a platform or a project. The difference is rarely visible in a term sheet, and almost always visible in the code.