A technical diligence report runs long, and length is misleading. The findings that determine whether a deal happens, at what price, and on what terms are a short list, and they are rarely the ones engineers most want to talk about. Test coverage, framework age, and architectural taste almost never change a transaction. Ownership, licensing, concentration, and undisclosed incidents do.
This page orders findings by consequence rather than by area, and it is written to be read from either chair. A buyer can use it to sequence a review so the fatal questions get asked in the first week rather than the fourth. A seller can use it as a preparation list: nearly everything in the top tier is inexpensive to resolve if you start a year before a process, and close to unresolvable once a bidder has already found it.
Tier one: findings that can end a transaction
These share a property. They are not conditions of the software that can be improved with time and money. They are facts about the past that cannot be changed after the fact, or dependencies that cannot be replaced inside a deal timeline.
Ownership that cannot be established
The buyer is purchasing the right to use and sell the software. That right has to be traceable to every person who wrote a material part of it. In practice the gaps appear in two places: contractors engaged on a purchase order or a handshake with no assignment language, and founders who wrote the original system before the company existed and never assigned it afterward. Both are common, and neither is visible in the code.
A reviewer finds this by comparing commit authorship against the list of employment agreements and contractor agreements, then asking about every name that does not appear on both. Counsel decides what the gap means. A seller fixes it by running that comparison themselves and obtaining confirmatory assignments while the relationships are still cordial and nobody has heard the word acquisition.
Open source obligations that conflict with how the product is licensed
Open source components carry conditions. Some of those conditions interact awkwardly with a product that is distributed to customers or embedded in a device, and the interaction depends on the specific licence, how the component is linked or included, and how the product reaches the customer. That analysis is legal work. What a technical review contributes is a complete and accurate inventory: every direct and transitive dependency, its declared licence, and how it is incorporated.
The finding that stalls deals is not a particular licence. It is the absence of an inventory, which means neither side can say what obligations exist. A seller who maintains a generated dependency manifest and has had counsel review it once has removed a weeks-long unknown from the process.
Concentration in a customer or a dependency
Two versions of the same risk. Commercially, a large share of revenue sitting with one customer means the buyer is underwriting that relationship rather than the business. Technically, an architecture that rests on one vendor API, one unmaintained library, or one hosting arrangement with no substitute means a change outside the company's control can stop the product.
Both are found by asking what happens if it goes away. The answer is either a documented alternative with a cost and a timeline, or a silence. Sellers cannot diversify revenue on demand, but they can usually reduce technical concentration by isolating the dependency behind an internal interface.
An undisclosed security incident
An incident that was handled and disclosed is a diligence item. An incident the buyer discovers in logs, ticket history, or a former employee's account after management said there had been none is a different problem. It changes the buyer's view of everything else management has represented, and that is usually the thing that ends the deal rather than the incident itself.
The correct handling is to surface incident history early: what happened, what was affected, what was notified, and what changed afterward. Whether notification obligations were met is a legal question for counsel.
Customer data used in ways the contracts do not permit
This finding usually surfaces as a mismatch, not as misconduct. Production data copied into a staging environment. Customer records used to train or evaluate a model. A subprocessor added without the notice the contract requires. Data retained past the period the agreement specifies. Each is ordinary engineering practice that nobody checked against the commitments in the master services agreement or the data processing terms.
A reviewer maps where customer data physically goes and hands that map to counsel alongside the contract terms. A seller does the same exercise in advance, and where the two do not line up, either the practice changes or the contract does. Both take months, which is why this is preparation work rather than deal work.
Tier two: findings that move price and terms
These do not stop a deal. They change what it is worth, because they represent spending the buyer will have to do that is not in the model.
A system that cannot carry the plan
The financial model assumes growth in customers, transactions, geographies, or all three. The question is whether the current system reaches those numbers with incremental investment or only with a rebuild. This is answered with evidence: current load against measured headroom, the cost curve of recent features, and the specific components that would have to be replaced. A rebuild nobody has priced is a real liability, and a buyer who finds one will move it into the purchase price.
Knowledge held by two people
In most small engineering organizations, a handful of people can explain why the system is the way it is. If they leave shortly after closing, the buyer owns a system nobody can safely change. The finding is not that these people exist, which is normal, but that there is no retention arrangement and no written record of what they know. Sellers reduce this by documenting decisions and runbooks, spreading ownership beyond one person per critical area, and settling retention before a process starts.
Tier three: findings that become a hundred-day plan
The remainder is the list every reviewer produces and no reviewer should lead with. Absent or unreliable automated tests. Deployment performed by hand by one person. Dependencies past end of life. Backups that exist but have never been restored, so nobody knows whether the recovery plan works. Monitoring that alerts on nothing. Access that was never removed for departed staff.
These are cost and schedule, not risk to the transaction. They belong in an integration plan with owners and dates. A buyer who argues price on them loses credibility on the findings that matter.
Findings by severity
| Finding | Severity | Typical deal consequence | How a seller fixes it in advance |
|---|---|---|---|
| IP ownership cannot be established for contractor or founder contributions | Deal-breaking | Diligence pauses; may require confirmatory assignments before signing, or an indemnity and holdback | Reconcile commit authorship against agreements and obtain confirmatory assignments, with counsel, twelve months out |
| Open source obligations unassessed against how the product is licensed | Deal-breaking until assessed | Extended legal review; possible remediation condition to closing | Maintain a generated dependency and licence inventory and have counsel review it before a process |
| One customer carries a large share of revenue | Deal-breaking to severe | Revised valuation, earn-out tied to that relationship, or withdrawal | Diversify where possible; otherwise document contract term, renewal history, and relationship depth |
| Architecture rests on a single vendor or unmaintained dependency | Severe | Price adjustment sized to the replacement cost | Isolate the dependency behind an internal interface and cost a documented alternative |
| Security incident not disclosed by management | Deal-breaking | Loss of trust in all management representations; frequently terminal | Disclose incident history up front with scope, response, notifications made, and remediation |
| Customer data handled outside what customer contracts permit | Deal-breaking until assessed | Legal review, remediation conditions, indemnity, or repapering of customer agreements | Map where customer data goes, compare with contract terms with counsel, and close the gap |
| System cannot reach the volumes in the model without a rebuild | Severe | Purchase price reduced by the unbudgeted rebuild; investment plan renegotiated | Measure headroom, price the work honestly, and present it as a plan rather than let a buyer find it |
| Critical knowledge held by one or two people with no retention arrangement | Severe | Retention packages, escrow tied to key personnel, or a lower price | Document decisions and runbooks, spread ownership, and settle retention terms before going to market |
| No automated tests; deployment performed manually | Priced | Hundred-day plan item; small effect on price | Automate deployment and add tests around the highest-risk paths |
| Dependencies past end of life | Priced | Remediation cost included in the integration budget | Upgrade the components with published end-of-life dates and keep the inventory current |
| Disaster recovery documented but never tested | Priced | Integration plan item; occasionally an insurance condition | Run one restore, record the elapsed time and the gaps, and fix what the test exposed |
Seller-side preparation
None of this makes a weak business strong. It removes the findings that make a buyer wonder what else has not been looked at, which is what turns a manageable diligence process into a repriced one.
- 1
Reconcile every material contributor against a signed agreement that assigns their work, and take gaps to counsel before anything else.
- 2
Generate a full dependency and licence inventory, keep it current in the build, and have counsel review it once against how the product is distributed.
- 3
Write down the incident history, including what was notified and what changed afterward, and be prepared to disclose it early.
- 4
Map where customer data actually travels, compare that against the customer contracts and data processing terms with counsel, and fix whichever side is wrong.
- 5
Identify each single point of failure (one customer, one vendor, one person) and document either a substitute or an honest cost to build one.
- 6
Clear the priced tier last: automate deployment, upgrade end-of-life components, and test a restore so the answer to each question is a date rather than a promise.
The pattern across the top two tiers is that the expensive findings are cheap to clear early and nearly impossible to clear under a signed letter of intent. A contractor from four years ago will sign a confirmatory assignment in an ordinary week. The same request, sent while a transaction is known to be underway, becomes a negotiation.
Common questions
- Which technical finding most often ends a deal?
- Findings about ownership and disclosure, not code quality. An IP chain that cannot be traced to every material contributor, or a security incident the buyer discovers after being told there was none, are the two that most reliably stop a process. Both are about facts that cannot be changed later, which is why they carry more weight than any amount of technical debt.
- Can a technical reviewer tell us whether an open source licence is a problem?
- No. A reviewer can produce an accurate inventory of every component, its declared licence, and how it is incorporated into the product. Whether those facts create an obligation depends on the specific licence, the method of distribution, and the jurisdiction, and that assessment has to come from qualified counsel.
- How early should a seller start this preparation?
- Twelve months before a process is a reasonable target for the ownership, licensing, and data items, because each depends on other people cooperating on a normal timescale. The priced-tier items can be done in a quarter. Anything started after a letter of intent is signed is remediation under pressure, and it is both slower and more expensive.
- Does poor test coverage reduce the price?
- Rarely on its own. It appears in the report and it shapes the first hundred days, but buyers expect to find it in companies of most sizes. It matters more as corroboration: when weak testing sits alongside manual deployment and untested recovery, the pattern suggests an engineering organization that has never had to operate under load.
- What if we cannot fix a severe finding before closing?
- Severe findings that survive to the negotiating table usually become terms rather than walk-aways. Price adjustments, escrow, indemnities, retention packages, and conditions to closing are all normal instruments for this. The outcome is generally better when the seller raises the finding first and brings a costed plan than when the buyer discovers it.
- Should the same team do the technical review and the remediation?
- It creates an obvious incentive problem if the reviewer is also bidding on the fixes, so the conflict should at least be disclosed and priced separately. What matters more is that the review produces findings a buyer can act on: severity, evidence, and a cost estimate for each item. A report that only lists observations leaves the deal team no better informed.