Selling Your Company? What a Buyer's Technical Due Diligence Will Find, and What to Fix First

You have decided to sell, or you may in a year or two. At some point a buyer will send specialists to read your code, your contracts and your accounts. Here is what they tend to find, what each finding does to the deal, what you can honestly check yourself and where you need specialists, and why a strong pitch deck comes after all of it.

IN SHORT

What buyers actually check

A buyer's technical due diligence asks five questions: who legally owns the code and the accounts, what open source licenses require of you, how exposed the system is, what has happened to its data, and how much depends on one or two people. Most findings change the terms of a deal instead of ending it: a lower price, a larger escrow, work to finish before closing, or a delay.

The seller's real advantage is time, and it should not be mistaken for ease. The same repair costs far less in the months before a sale than in the middle of a deal, against a deadline, with an auditor watching and lawyers billing on both sides. But the checks in this article only show an owner where to look. A review a buyer will respect takes people with long experience in M&A, sometimes licensed, and an analytical team who can read someone else's code from end to end, and that work is neither free nor quick: the ideal preparation for a sale takes about a year, and four to six months is the minimum, for a small product and a deal of a few million. The crown of it all is a strong pitch deck that argues for the price.

We see this from the side of the people who run these reviews. At Peretz Agency, a technical due diligence review is led by Valeriya Chumachenko, who has more than ten years of experience in technology M&A, with our developers on the code, the hosting and the data. The buyer's version of this checklist is in How to Audit a Website or Digital Product Before You Buy It. This article turns it around and asks what you, the owner, should do first.

Nearly every finding is cheaper to fix before anyone is waiting.

THE MECHANISM

How a finding reaches the price

The best-known example is large enough to be documented in a public filing. In February 2017, after Yahoo disclosed its data breaches, Verizon and Yahoo agreed to cut the price by $350 million, leaving the deal at about $4.48 billion. Yahoo also stayed responsible for half of certain cash liabilities from the breaches after closing.

Marriott shows the opposite order, when the finding arrives after the deal. The attack on Starwood's systems began in 2014, before Marriott offered to buy the company, and went undetected until September 2018. The UK regulator fined Marriott £18.4 million, and the problem it inherited became its own.

Those are giants, but the mechanism scales down. In a mid-size private sale, doubt usually becomes money held back. The 2026 SRS Acquiom study of more than 2,300 private-target deals, as summarized by the law firm Fasken, puts the median of all escrows in 2025 at 10% of deal value, and 2.8% where the deal had representation and warranty insurance. Average escrows grew from 2024 to 2025. The same summary reports that 22% of deals had no cybersecurity representation from the seller, up from 5% in 2024. Sellers, in other words, have become less willing to promise, and a buyer who does not get the promise has a reason to look harder.

Here is how we would expect common findings to travel through a deal. The actual terms always come out of negotiation, so treat this as our reading and not as a market standard:

CODE OWNERSHIP

Paying for code is not owning it

This finding surprises owners most, because the invoices were paid. Under US law, a transfer of copyright ownership is not valid unless it is in writing and signed by the owner of the rights. Work by employees within the scope of their job belongs to the employer. Work by outside developers follows different rules.

The US Copyright Office's Circular 30 sets four tests for a commissioned work to count as made for hire: it must fall into one of nine listed categories, there must be a written agreement, the agreement must expressly say so, and all parties must sign. The nine categories include translations, compilations, tests and atlases. Ordinary application code does not sit comfortably on that list, which is why contracts usually carry an express assignment as well. Take this chapter to your deal lawyer, because we are engineers and not attorneys.

The gaps tend to sit in the same places:

• Code the founder wrote before the company existed, which the company never formally received.
• The first freelancer, paid on a handshake or a two-line email.
• An agency contract that says nothing about who owns the result.
• A contractor's own library, reused in your product under terms nobody wrote down.

There is a first look you can take this afternoon, and it only tells you where to ask questions. In your repository, the command git shortlog -sne --all lists everyone who has committed code, with a count and an email address. Put that list beside your employment contracts and contractor agreements. Each name without a signed paper is a line for your lawyer. Git will miss code uploaded in one bulk commit and agency staff who shared one account, so ask about those as well. A clean list proves nothing by itself; tracing who wrote what is part of the specialists' job.

Do this while former contractors still answer email and part on good terms. Someone who hears about a sale at the moment you ask for a signature has leverage, and a deadline makes it worse.

Accounts come next, and they are simpler. A domain registered to the founder personally, analytics under a former employee's account or code in an agency's repository can all be moved with little fuss when nobody is in a hurry. We wrote about this in Most Companies Don't Own Their Website and in What You Own vs What You're Renting. On our own projects, the code, deployment commands and rollback procedure are handed over under the contract, because a solution built around a business should belong to that business.

An invoice proves you paid. Only a signed paper proves you own.

AI-WRITTEN CODE

The new question in the room

A buyer's contract normally asks you to state that the company owns its code. That sentence has become harder to sign. The US Copyright Office's January 2025 report concludes that, given current technology, prompts alone do not make the user the author of the output. Protection remains where AI is used as a tool and a human determines the expressive elements, and AI material inside a larger human work does not bar protection for the human part. Decisions are case by case.

The report gives no rule for a repository, and nobody can tell you today what percentage of generated code is safe. What you can do is keep evidence that people were in charge: a written policy on which tools are allowed, code review history showing that developers chose, changed and rejected what the tools produced, and a note of which modules were generated with little editing.

Licenses are the second half of this question. Black Duck's 2026 white paper on open source risk in M&A points out that AI assistants increasingly inject snippets into code, and that license obligations apply to snippets however small. If your first version was built mostly with AI tools and investors are about to look at it, that is what our MVP review is for. A separate question, whether the "AI" in your deck is really yours, is covered in The AI Wrapper Problem.

OPEN SOURCE

What the audit report will say

Buyers of software-heavy companies often pay an outside firm to scan the code, partly because targets generally do not share code with potential acquirers. So the auditor sees what the buyer cannot. Black Duck sells these audits, so read its numbers with that interest in mind, and note that it mostly audits software companies. Its data covers audits from November 2024 to October 2025:

With numbers like these, a finding on its own is no scandal. Almost everyone has one. What hurts a seller is hearing about it for the first time from the buyer's auditor, with no answer ready. Black Duck lists the usual results of license problems: extra acquirer protections, remediation before closing, escrows, price reductions and delay.

The white paper also says 16% of the components it identified needed deeper analysis, since they entered outside package managers: copied vendor folders, pasted snippets, code from AI assistants. Those are the ones your own quick scan will miss.

Whether a conflict matters depends on how the business earns. The white paper describes copyleft terms as a concern for companies that distribute software, so a downloadable product and a site you only host may get very different answers from a lawyer. Start with an inventory. On a PHP project, composer licenses prints every dependency with its license, and npm projects have similar tools. Remove what is unused, replace what conflicts, and write down why the rest is acceptable. Such a command reads only what is declared, so it will not catch the copied and pasted code above. Finding that takes specialist scanners and people who can interpret them.

As for the 97%, nobody expects zero known vulnerabilities. A buyer wants to see that someone patches on a schedule and can show the last few rounds. Our article on how business websites really get hacked sets out what to fix first.

OLD STACK

An old version is a number

An unsupported framework rarely stops a sale. It becomes a deduction, and the only open question is whose estimate is used. As of November 2026, these are the published end dates for security fixes:

If you leave this to the buyer, their team will price the upgrade with a safety margin, because they do not know your system and they carry the risk. If you arrive with your own number, the conversation changes: here is the current version, here is what blocks the next one, here is a developer's estimate. Better still, finish the upgrade first. The method is to step through versions one at a time on a closed copy, as in Six Laravel Versions in Three Days and Upgrading an Old Laravel or PHP Site in 2026. Do not take those three days as a benchmark: that was a system its team knew well, and a stranger's code with no tests can take months. The practical side is our website modernization service.

One warning from the same logic. In our view, the months before a sale are a poor moment to begin a full rewrite. An old system with a known upgrade cost is easy to price. A half-finished replacement running beside it leaves a buyer pricing two systems and a plan, and that review tends to go badly. Hidden technical debt is easier to explain than an unfinished migration.

PAST INCIDENTS

What you cannot prove

Expect plain questions. Have you had a security incident in the last few years? Were customers notified? Who has administrator access today? When did someone last restore a backup and check that it worked? The hardest answer is "we don't think so", because a company that keeps no logs cannot show that nothing happened. Marriott's case is a useful reminder of how long an intrusion can sit unnoticed.

So write the history down while you have time: each known incident, what was done, what changed afterwards. Your lawyer decides how it is disclosed, and you want the facts ready when that conversation starts. Test a restore as well, since an untested backup is a promise nobody has checked.

Keep real customer data out of the data room. A buyer can learn what they need from the structure, from counts and from an anonymized copy. Access for reviewers should follow a signed NDA and be read-only, which is how our own reviews begin. Ask your lawyer as well whether your privacy policy allows customer data to pass to a new owner, because the promise you made to customers travels with the data.

KEY PEOPLE

What lives in two heads

A reviewer will ask who can deploy, who knows why the billing integration behaves as it does, and what happens if that person leaves in the month after closing. We covered the business side in Founder Dependency: The Discount Nobody Puts in the Deck. The technical test is simple. Give a developer who has never touched the system your documentation and ask them to set it up, deploy a small change and restore a backup. Everything they had to ask about is your list of missing documents.

If your developers come from an outside team, tell the buyer early and show the contract, the handover terms and the access list. Outside teams are normal. An outside team holding the only copy of the keys is the finding.

THE REAL REVIEW

What an owner cannot check alone

Everything above can create a false sense of safety, so here is the limit of it. Your own commands and checklists find what is easy to find. They give you a list of questions, and a buyer will not accept that list as evidence.

A review that holds up in a deal needs people who have worked in M&A for years, sometimes licensed, and an analytical department who understand someone else's code from top to bottom. They read an unfamiliar system without its authors in the room, follow the business logic through it, reproduce each finding, and separate what is dangerous from what merely looks old. Then they translate it into consequences a lawyer and a buyer can use. Scanners and AI-assisted code reading shorten parts of this, but they do not replace checking real access, real data and real contracts.

Your own developers cannot do this for you, however good they are. They wrote or inherited the system, they know where they did not look, and a buyer has no reason to take their word for it.

Be realistic about the cost and the effort too, and keep two things apart. The assessment is a defined piece of work. As of November 2026, the Technical Due Diligence Session costs $1,500 and a full review starts from $7,500, priced on the scope of the business. It usually takes five to ten working days and gives you an assessment and a direction: what needs work and what needs very deep work. Your own team's time goes into it as well: giving access, answering questions, finding old contracts.

The real work comes after that, and it has no honest starting price, because it depends on the product and we have to see the product first. Ideally you give it a year, so that the company can be properly presented to investors. Four to six months is the minimum, when the product is fairly small and the deal is worth a few million. The teams it needs are sometimes far from small.

This is where we have a real advantage. Peretz works with a large pool of vetted developers of European and Ukrainian origin at reasonable prices, so when a product needs a bigger dedicated team for those months, we can put one together.

THE PITCH DECK

The layer that sells

A clean system does not sell a company. The technical work protects the price; the pitch deck is what argues for it. Whether you call it a deck, a teaser or an information memorandum, it decides whether a serious buyer opens your data room at all, and it gets read when you are not in the room.

It is the crown of everything above. We make pitch decks ourselves, and they are our favourite part of the work, because reaching the deck means the product is ready.

The order matters. A deck written before the review is full of claims the auditors may overturn, and one overturned claim makes a buyer doubt the rest. A deck written after it can state plainly what the company owns, what it rents, what is known to be wrong and what fixing that costs. That candor reads as strength, because the buyer's team is going to find the same things anyway.

A strong deck does a few things well:

• It says why this particular buyer should want this company, with reasons and not a long list of names, as in Buyer Universe.
• It shows the economics buyers actually price: recurring revenue, retention and margin, as we explain in Why Tech Companies Get Valued on Different Math.
• It shows the business running without the founder as the operating system.
• It tells one story shaped by how this business earns, and it does not look like a template with your logo on it.

Then test every technical line against the data room. If they disagree, the buyer stops trusting the deck:

The review protects the price. The pitch deck argues for it.

Do not go to the bankers with the deck before you have done this work, a point we make in Before You Hire Bankers, Diagnose the Business.

The deck itself, slide by slide, and what has to stand behind each claim, is the subject of How to Present Your Company to a Buyer So Its Story Survives Due Diligence.

TIMELINE

A year before the data room

A year is the ideal, and this is how we would divide it. Four to six months is the minimum, for a fairly small product and a deal of a few million, and then the same steps run closer together. The sequence holds either way, and the pitch deck comes last.

If you have not decided whether to sell at all, begin one step earlier with the Exit & Succession Readiness Session: a session costs $1,500 and a preparation program starts from $5,000. It concerns the owner's decision about the future and is not a valuation. Like the review, it gives an assessment and a direction, and the repairs themselves are separate work. When no deal is planned and you want to see what the company owns and rents, the Digital Ownership & Debt Audit starts from $1,000, and from $3,000 for larger businesses.

A seller can also order the same review a buyer would, through the Technical Due Diligence Session at $1,500 or a full review from $7,500. We can name a price for the work that follows only after seeing the product. You get a written findings report and a session where we walk you and your advisers through it. Every review starts with how this particular business earns, since a license conflict that is serious for a company shipping software may be a footnote for one running a store.

QUESTIONS

Frequently asked questions

What does technical due diligence look at when you sell a company?

The code and its architecture, hosting and access, who owns the domain, repositories and accounts, licenses, security, data, and how much of the system lives in the heads of one or two people. Good reviewers start from how the business earns, and only then open the code.

Should a seller do technical due diligence before the buyer does?

If technology is a real part of the value, yes. An independent review shows what a buyer's team will find while you still have time to fix it or prepare an honest explanation. A year is ideal and four to six months is the minimum, so leave room for the repairs.

Can I prepare for technical due diligence on my own?

Partly. An owner can collect contracts, move accounts and list the obvious gaps, and that saves time and money later. A review a buyer will respect needs people with long experience in M&A, sometimes licensed, and an analytical team who read someone else's code from end to end. It is paid work and it takes real time.

How long does it take to prepare a company for sale, and what does it cost?

About a year is ideal. Four to six months is the minimum, for a small product and a deal of a few million, and the team is sometimes large. The assessment takes five to ten working days: a session costs $1,500 and a full review starts from $7,500. The work that follows has no honest starting price, because it depends on the product.

When should the pitch deck be written?

After the technical review and the main repairs, so its claims can survive the buyer's auditors. Every technical line in the deck should point to a document in the data room. A deck written first tends to promise things the review later overturns. We make pitch decks ourselves, once the product is ready.

Can technical findings kill a deal?

They can, though most change the terms: a lower price, a larger escrow, conditions before closing or a delay. Black Duck lists these as the usual results of license problems. Verizon and Yahoo cut the price by $350 million after the breaches and went on with the deal.

Do buyers get to see my source code?

Usually not directly. Black Duck notes that targets generally do not share code with potential acquirers, so independent auditors review it under an NDA and report their findings to the buyer. Agree the access terms with your lawyer before anyone receives a copy.

What if a former contractor cannot be found or will not sign?

Tell your lawyer early. The options depend on how much of the code is theirs and what your agreement says: a new agreement, rewriting that part, or disclosing it and accepting specific protection for the buyer. Discovering this yourself gives you time to choose.

Is code written with AI tools a problem in a sale?

It can raise questions, without being a bar to a deal. The US Copyright Office says prompts alone do not give authorship, while human selection and editing can be protected. Keep a tool policy and a code review history, and scan generated code for licenses like any other code.

Sources

• Yahoo and Verizon press release on the amended terms, SEC filing, February 21, 2017
• Black Duck: 2026 Open Source Risk in M&A by the Numbers
• U.S. Copyright Office: Circular 30, Works Made for Hire
• U.S. Copyright Office: Copyright and Artificial Intelligence, Part 2: Copyrightability, January 2025
• Fasken: Key takeaways from SRS Acquiom's 2026 deal terms study, May 7, 2026