Preparing for a sale: the seller's technical review

Preparing for a sale is preparing for a technical review in which every finding has a price. A fundraising reviewer writes a report and the investor decides whether the findings matter. A buyer's reviewer writes the same report and the buyer's counsel turns each finding into a clause. This page is the seller's side of that review. The buyer's side, what a sell-side review looks like from the acquirer's chair and how it is scored, is on sell-side technical due diligence, and the pillar page on preparing for technical due diligence puts this page in sequence.

Morgan Lewis's note of 1 June 2026 on technology M&A, by Nancy Yamaguchi and Jason W. Capps, describes technical diligence as having become "critical alongside legal and financial review", with a focus on data rights, IP and employee or inventor ownership, and open-source compliance, and describes transaction documents evolving to address AI and data risk through targeted representations, special indemnities, special escrows and staged investments [7]. Reveneau's preparation method for a seller starts from that list of clauses and works backward: for each clause a buyer might ask for, which finding would justify it, and can that finding be closed before the buyer's reviewer opens the repository.

Which technical findings become which clauses?

A finding becomes the clause that protects the buyer from its cost. The mapping below is the one to prepare against, and it is drawn from the instruments Morgan Lewis names [7]:

Finding	What the buyer fears	The clause it becomes
A contributor with no signed IP assignment	The company does not own part of its code	An IP ownership representation, with an indemnity behind it
Copyleft code in a distributed product	The proprietary code must be published	An open-source compliance representation, a special indemnity, or a condition to close
Customer data held without a clear legal basis	Regulatory exposure transfers with the company	A data compliance representation and a special escrow
Code generated by AI with no trail	Unknown provenance, unknown quality	An AI compliance representation, a staged payment tied to remediation
A core system one person can change	The value walks out after closing	Retention conditions on that person, staged payments
A security incident not disclosed	Liability the buyer did not price	A disclosure schedule item, and a breach of representation if omitted

Every row on the right side is money or time held back from the seller. Every row on the left side is something the seller can find first.

What review should the seller run first?

The full one. Use the seven headings of Matt Van Itallie's checklist of 26 October 2022 (product roadmap, code quality, intellectual property, security, development process, engineering team contributions, DevOps) and its windows: incidents within the past three years, twelve months of development activity, twelve months of ticket history [1]. Answer each item with an artefact per what a technical review asks for, and build the seven-folder engineering data room.

Then go further than a fundraising review would on the three headings that produce clauses. Under intellectual property, the checklist asks for IP assignment and confidentiality agreements for employees and vendors, software escrow status, and how third-party code with copyleft licences is handled [1]. At a sale, each of those is checked contributor by contributor and dependency by dependency, and the seller should do the same first. Under security, the three-year incident window becomes a disclosure schedule. Under engineering team contributions, the question of what happens if the key developers leave becomes a retention negotiation, and the seller should know before the buyer does which people the buyer will name.

Van Itallie's eight reviewer questions, published on 25 October 2022, still apply, and the fifth, "Do you know what third-party code you are using?" [2], is the one a buyer's counsel will spend the most time on.

Which findings can be closed before the buyer arrives?

Ownership and licence findings, and most of them close in weeks rather than months.

Ownership. List every person who has ever committed code, including contractors and the founder's friend who helped for a month in year one. For each, find the signed IP assignment. Where there is none, get one signed now. A signature obtained before the buyer's review is an artefact; one obtained after the buyer found the gap is a condition to close, and the person who has to sign it now knows the deal depends on them.

Licences. Generate the dependency inventory with a tool, read the licence of every entry, and for every copyleft entry record whether the component is hosted or distributed. Morgan Lewis's note of 5 June 2026 on open-source diligence lists six areas a buyer asks about: a written open-source policy, employee training on licence obligations, contributions to open-source projects, monitoring and tracking of usage, regular scans, and an approval process for copyleft-licensed software [6]. The same note explains the fear: proprietary code packaged with copyleft code and shipped to customers can be required to be made public, "which would diminish the commercial value almost immediately". Replace any copyleft dependency in anything you distribute, write the policy if there is none, and run the scan so that the history starts before the buyer's review. The investor-side detail is on open-source licence due diligence.

Single-name systems. These take longest, four to six weeks per system, and a sale often does not give you that. Where you cannot add a second name, document the system to the point where a second engineer could take it over, and be ready for the retention conversation. The page on what investors look for in a startup's codebase covers the team map that shows where these are.

How should the seller present the findings that cannot be closed?

As a priced list, before the buyer's reviewer finds them. Each item carries what it is, what it would cost to fix, how long it would take, and what the seller proposes: fix before closing, fix after closing at the seller's cost, or accept the clause. A buyer who receives that list prices the items on it. A buyer who finds the same items prices them higher, because now they are also pricing what else the seller did not say.

This is the sale version of the rule that runs through this whole guide: a known problem with a plan is a line item, and the same problem as a surprise is a trust problem. At a sale, the trust problem has a number attached, in the size of the escrow.

The presentation also needs to survive the buyer's integration team, who will read the diligence report as the start of their plan. The pages on merging two codebases after an acquisition and turning the diligence report into the first-year plan describe what happens to your findings after closing, and a seller who has read them presents the findings in the form the integration team will use.

What about AI-generated code at a sale?

It arrives as a representation. Morgan Lewis's June 2026 note describes buyers acquiring data, models, infrastructure and talent alongside products and deal documents carrying AI and data compliance representations [7]. For a seller whose code was written with AI tools, that means the four questions on preparing an AI-written codebase for review (the share, the review trail, the test or evaluation history, and the security scan) become the substance of a warranty the seller signs. Prepare the answers as if you were going to warrant them, because you are.

How long does seller-side preparation take?

Longer than for a round, and it should start before the sale process does. The ownership and licence work is two to four weeks if the contributor list is short and the inventory is clean, and longer for every missing signature and every copyleft replacement. The three-year incident history, the data map and the security evidence take a further two weeks to assemble if they exist and a quarter to create if they do not. The single-name systems take four to six weeks each and should start first.

A seller who begins this work when the banker is engaged arrives at the buyer's review with a data room, a priced list of open findings and a plan for each, and a buyer's reviewer who confirms rather than discovers. The two-week checklist covers the final fortnight before the buyer's reviewer starts; the work above is what fills the weeks before that.