What a technical due diligence reads, and what it does to the deal

The letter of intent is signed, exclusivity has started, and the clock is running. The financial and legal workstreams come with checklists everyone on the deal team recognizes. The technical workstream often arrives as a request list few people can fully read, followed by a report written for engineers.

That gap matters, because technology findings rarely end a deal. They change its terms. A buyer who cannot tell a Critical finding from a Low one either overreacts and loses a good company, or underreacts and pays for the fix after closing, out of the budget meant for growth.

This is the reviewer's view of the work: what a technical due diligence reads in a software company, layer by layer, what evidence stands behind a finding, how findings are rated, and how a rating becomes something your counsel can work with.

Start from the deal thesis

A technical review is not a grade for code style. It answers one question: does the technology support the price and the plan behind it? The plan decides where the reviewer looks hardest, so the first conversation is about the investment case, not the repository. What revenue, margin and growth does the price assume? What will change after closing? Who will run the product?

The same company reads differently to different buyers:

• Private equity, platform deal. Can the product carry add-on acquisitions and more customers without the cost of running it rising faster than revenue?
• Private equity add-on or strategic buyer. What happens at integration: identity and single sign-on, the data model, hosting, and vendor contracts with change-of-control terms. Some of the product may be retired, and the review should say which parts.
• Search fund or independent sponsor. Often a founder-run company with the founder as the main source of technical knowledge. The question is whether the product keeps running when that person steps back. A lender or investors may also want an independent opinion on file.
• Advisor on either side. Which findings are likely to surface in the buyer's review, and whether they can be explained with evidence before they become a negotiation point.

A cloud bill that grows faster than revenue matters a great deal to a buyer paying a multiple of margin. A dated admin screen used by three staff members may not matter at all. Starting from the thesis keeps the report about the deal.

Six layers, read from the ground up

We read every software company in the same six layers, in the same order. The order is deliberate. Problems in the lower layers, such as who owns the code or the cloud account, can stop a deal on their own. Problems higher up usually change the cost of ownership rather than the yes or no.

The lower layers: ownership, infrastructure, data

Ownership comes first because the price assumes the company controls what it sells. Under US copyright law, a transfer of ownership must be in writing and signed, so a paid invoice to a contractor is not proof of ownership. The reviewer compares the list of people who committed code with the signed employment and contractor agreements, and checks the early years most carefully. Open source sits in the same layer: an inventory of components and their licenses, and how the product reaches customers. A product that is shipped or installed can face different copyleft obligations than one that is only hosted, and counsel decides what applies. Where code was written with AI assistants, the reviewer looks for a tool policy and review history that show people directed the work.

Infrastructure and data are read against the financial model and against the company's own promises. Does the cost per customer hold as usage grows? Is the parent or the founder quietly paying for shared hosting? Does the privacy policy describe what the system actually does, and does it allow customer data to pass to a new owner? That last question goes to counsel with the facts attached.

The upper layers: code, security, team

In code, the reviewer does not argue about style. The questions are how safely and how quickly the product can change: framework and runtime support dates, test coverage where money moves (billing, authentication, integrations), how a release reaches production and how one is undone. Samples are read line by line where risk sits. A useful check is the gap between the product described in the pitch materials and the one in the repository.

Security is mostly the basics: multi-factor authentication, former staff and contractors who still have access, passwords and keys in the code history, and whether logs exist that could support a statement that no incident has occurred. The team layer often comes out of interviews. When the same person answers every hard question, that is the clearest measure of key-person risk the review will find.

What counts as evidence

A statement from the seller is a lead. An artifact is evidence. Every finding in a review should say where it came from: seen directly in a system with read-only access, read in a document, heard in an interview, or not seen at all. A buyer should be able to tell these apart on the page, because a finding built on one interview carries less weight than one seen in the cloud console.

A typical first-week request list for a software company looks like this:

• Read-only, named accounts for the code host, the cloud console and the main admin tools.
• A list of every account the business depends on, with the registered owner and the card that pays for it.
• Employment and contractor agreements with their IP assignment clauses, including the earliest ones.
• A dependency and license inventory, or permission to produce one from the repository.
• Cloud and software invoices for the last twelve months.
• Backup configuration and a record of the last restore test, or agreement to run one.
• The list of people with administrator rights and with MFA enabled.
• The incident log, or a written statement that none exists.
• Customer contracts with uptime, security or data terms.
• Architecture notes, runbooks and an org chart that includes contractors.

Two things are not on the list. Reviewers do not need a copy of the source code or of the production database. Access is read-only, time-limited and closed at the end, as set out in our access protocol. And anything the reviewer could not see is written down as a limit of the review. Underwriters of representations and warranties insurance read that section closely, because areas that were not examined tend to be excluded from cover.

The seller sees the same list from the other side of the table. Our engineering partner PERETZ covers that side in Selling Your Company? What a Buyer's Technical Due Diligence Will Find, and What to Fix First. For a buyer, the practical point is simple: a seller who has prepared hands over evidence in days, and the review time goes to the parts of the system that matter.

How findings are rated

Every finding gets one of four ratings on our severity scale:

• Critical. Can stop the deal or should be resolved before closing. The company does not control something it sells.
• High. Likely to affect price or terms. Needs a plan in the first 90 days after closing.
• Medium. Raises the cost of owning the product. Belongs in the first-year plan.
• Low. Hygiene. Worth fixing when the team is working in that part of the system.

Severity and cost are separate measures. A Critical finding can be cheap to fix: moving a domain into the company's name may take an afternoon. A Medium finding can be expensive: a framework upgrade that touches every module may take months. Reading severity as a price tag is the most common mistake a deal team makes with a technical report.

Ratings also depend on the thesis. A copyleft component may be Critical for a company that ships software to customers and a footnote for one that only hosts it. The reviewer rates on the facts and the stated business model, and marks where counsel's view could move the rating.

Each finding is written so it can be lifted straight into a board paper or a negotiation memo. A generic, fictional illustration:

The production cloud account is registered to a former contractor's personal email. Layer: Ownership & IP. Severity: Critical. Evidence: account settings viewed read-only; the billing card belongs to the founder; no written agreement covers the account. Impact: the company cannot transfer or fully secure its own hosting. Cost to fix: one to three days of engineering, assuming the contractor cooperates; longer if the account must be rebuilt. Recommendation: transfer to a company-owned account before closing.

The structure of the full report follows the same logic: a two-page summary of what affects price or terms, a findings register, a layer-by-layer view that includes strengths, a fix plan with cost ranges, and the questions and limits.

How findings turn into deal terms

We do not negotiate and we do not give legal advice. What follows are the usual routes a technical finding takes into a transaction. Each one is a point to raise with your counsel, who will weigh it against the rest of the deal.

Most findings end up in the last row. The fix plan becomes the new owner's first technical budget and hiring plan, and it is often the most used part of the report after closing.

Points worth raising with counsel

Known issues are usually excluded from representations and warranties insurance. A finding that surfaces during diligence may therefore need its own protection in the purchase agreement, because the policy may not respond to it. This is one reason a clear finding found early is worth more than a vague one found late.

The cost range is what makes a finding usable in negotiation. Counsel and the deal team need a number with its reasoning: who does the work, from what starting point, and what must hold for the low end. A range without assumptions invites an argument about the number instead of the issue.

Watch for double counting. A cost that has already reduced the price should not also sit in an escrow sized for the same work. The findings register should make it easy to see which route each finding has taken.

Timing, access and the seller's team

Depth should match the stage of the deal. Before a letter of intent, or early in exclusivity, a red-flag memo looks for anything that could stop the deal or move the price, usually within 5 to 10 business days of access. Once the price is close to final, a full technical due diligence reads all six layers in depth, usually over 2 to 4 weeks inside exclusivity.

In practice, reviews lose more time to access than to reading. Named accounts, the first documents and the interview schedule should be agreed in the first days. Interviews go through the seller or its advisor and only with their consent. Many staff may not know a sale is under way, and the reviewer never asks them about the deal.

When the seller provides a vendor due diligence report, a buyer does not have to start from zero. The sensible approach is to check how the report was scoped, verify its main findings in the systems, and spend the saved time on what it did not cover or on what matters most to the buyer's own plan.

What to do next

If you have a signed letter of intent or expect one soon, agree the scope of the technical workstream with your counsel and advisor now, so access is ready when exclusivity starts. Share the investment case with the reviewer; it decides where the review goes deep. Ask for every finding to carry severity, evidence, impact and a cost range with assumptions, because those are the parts your counsel can use.

Our technical due diligence is written for buyers inside exclusivity, at a fixed fee agreed in writing before we start and with no success fee. We work for one side per deal. Common questions about scope, access and timing are answered in our FAQ.

Questions