You are buying a company whose value depends on software you did not build. The question is not whether the code is good. It is whether the asset is actually owned, whether it can carry the volume the model assumes, what it costs to run for five years, and which of those answers should change the price or the terms.
Diligence is time-boxed by the transaction, not by the work. Two to four weeks with one or two senior engineers is realistic for a single-product company. Work the areas in the order below, because the early ones can stop a deal.
What diligence asks that a code audit does not
A code audit asks how maintainable a system is and what it would take to improve it, and its conclusions hold regardless of who owns the company. Diligence is conditional: it asks whether a specific thesis survives contact with the system, so the same finding can be immaterial in one deal and disqualifying in another.
A monolith with no automated tests is ordinary maintenance if the thesis is to hold the business and collect cash flow. The same monolith is a serious problem if the thesis is to triple transaction volume in eighteen months. The code did not change. The thesis did. So the first thing to obtain is not repository access. It is a statement of what the buyer intends to do, with the numbers from the model attached.
- What the model assumes about volume, users, transactions, and geography over the hold period
- Which product capabilities the model assumes will be built, and by when
- Whether the plan involves integrating this system with an existing platform, or consolidating other acquisitions onto it
- What the buyer intends to do with the engineering team after close
Without those four answers you can produce a competent technical report that says nothing about the deal.
Ownership and provenance of the code
This goes first because it is the area most likely to affect the transaction itself rather than the valuation. If the company does not clearly own what it is selling, that is not something you price into a discount.
Establish provenance for every significant component. Ask who wrote it: employees, contractors, an outside agency, or a founder before the company existed. For anything not written by an employee under a normal employment arrangement, ask to see the agreement that transfers the work to the company. Contractors are the recurring gap, because early-stage companies engage individuals on informal terms and the paperwork sometimes does not exist.
Then inventory the open source. Generate a dependency manifest for every deployed artifact, including transitive dependencies, and record the declared licence for each. Note where components have been modified rather than used as published, and whether the software is distributed to customers or run as a hosted service, because that changes which obligations are in play.
Also confirm the boundaries of the asset. Who controls the repositories, cloud accounts, domain registrations, signing certificates, and app store listings? It is common to find one of these in a founder's personal account, and that gets fixed before close.
Key person concentration
In most companies under a few hundred people, the working knowledge of the core system lives with two or three engineers. Diligence has to establish who they are and what the business looks like if they are gone ninety days after close. Retention packages address motivation, not the fact that nothing is written down.
- Who are the only people to have deployed to production, restored a backup, or changed billing or pricing logic in the last year
- Whether any one person holds credentials, signing keys, or vendor relationships nobody else can access
- How long a new senior engineer takes to run the system from a clean checkout
- Whether business rules that carry money exist anywhere other than source code and one person's memory
- What the company's own answer is, and whether it matches the commit history and on-call records
Report this as an operational scenario, not a list of names. If the two people who understand the pricing engine leave at close, the usual consequence is six to twelve months in which the roadmap stops. That cost belongs in the model.
Scalability against the growth case
Do not ask whether the system scales. Ask whether it carries the numbers in the model. Take the peak volume the thesis assumes in year three, compare it to the highest volume the system has handled, and find out what sits between them.
The constraints are rarely where the seller expects. Compute is cheap to add. What usually limits growth is a single write-heavy database with no partitioning strategy, a batch process whose runtime grows faster than the data, a tenancy model that assumed one customer per deployment, or a per-call vendor whose cost curve breaks the unit economics first. Ask what the last capacity incident was: a fix that consisted of buying a larger instance tells you the headroom strategy has an end.
Where the model assumes geographic expansion or consolidation of other acquisitions onto this platform, test those specifically. Multi-entity separation, currency, and regional data residency are architectural properties, not features added later at moderate cost.
The true cost of ownership
The seller's engineering budget is a floor, not a forecast. Diligence has to estimate what the acquirer will spend to keep the system safe, supported, and capable of the roadmap.
Deferred work that has a deadline attached
Inventory every runtime, framework, database, and operating system version in production against its support status. Anything past end of life, or reaching it inside the hold period, is a dated obligation rather than abstract technical debt. Price each upgrade as a project with an owner and a window.
Debt that shows up as slower delivery
The rest of the technical debt matters only through its effect on throughput and incident rate, so measure the symptom: how long a small change takes to reach production, how often releases are reverted, and how much capacity goes to unplanned work. If sixty percent of engineering time keeps the system upright, the roadmap is being delivered by the other forty percent.
Whether the team can deliver the roadmap
Delivery capability decides whether the plan is achievable, and it is observable without judging anyone's code. Look at whether the team ships on a predictable cadence, whether changes are reviewed, whether more than one person can run the deployment path, and whether the team has ever delivered something the size the roadmap assumes.
Security, data, and third-party dependencies
Security findings rarely kill a deal on their own, but an undisclosed incident history changes what else you believe. Ask for the incident record, including near misses, and compare it with the logs and any customer notifications.
- Incident history, breach notifications, and what changed after each one
- How access is granted and removed, whether former staff still hold credentials, and whether administrative access requires a second factor
- Where customer data lives, what categories it includes, how long it is kept, and whether copies sit in laptops or test environments
- What the company has committed to customers and regulators about data handling, and whether the system enforces that or relies on process
- Any external penetration test or audit, and the remediation status of prior findings
- Every third-party service the product depends on, its term, its pricing basis, and whether it can be replaced
Vendor dependencies deserve particular attention in a transaction. Some agreements contain change-of-control provisions, and a dependency the business cannot operate without may require consent or reprice on transfer. Identify every material vendor, hand the contracts to counsel, and state plainly what stops working if a vendor withdraws.
What findings actually do to a deal
A report that ends in observations leaves the deal team doing the work you were hired for. Every material finding resolves into one of four outcomes.
- 1
Walk away: the finding contradicts the thesis and cannot be remediated at a price that preserves the return, such as core intellectual property the company cannot show it owns
- 2
Adjust the price: the finding is quantifiable future cost, so it becomes a line in the model rather than an argument
- 3
Make it a condition: the finding is fixable before close and cheaper to fix while the seller has an incentive
- 4
Carry it into the first hundred days: the finding is survivable, so it becomes integration work with an owner, a budget, and a date
| Area | What to request | What a finding usually means |
|---|---|---|
| Intellectual property and provenance | Contributor list by component, contractor and employee agreements, dependency manifest with declared licences | Usually a condition of closing; where ownership cannot be shown, a reason to walk. Routed to counsel |
| Key person concentration | Named owners per subsystem, on-call and deployment records, onboarding time for a new engineer | Retention terms, knowledge transfer as a condition, a funded documentation plan after close |
| Scalability against the model | Peak historical volume, largest customer usage profile, capacity incidents, storage and tenancy design | A price adjustment sized to the re-architecture, or a revision to the growth timeline |
| Cost of ownership | Version inventory against vendor support dates, engineering budget, share of unplanned work | Almost always a price adjustment; it is spend the seller's budget did not carry |
| Security posture and incidents | Incident and breach history, access review, penetration test reports and remediation status | Conditions before close for the urgent items, first-hundred-days work for the rest |
| Data protection obligations | Data inventory by category and location, retention practice, customer and regulatory commitments | Escrow or indemnity language drafted by counsel, plus remediation cost in the model |
| Third-party and vendor dependencies | Vendor list with terms, pricing basis, renewal dates, and any change-of-control language | Consents before close, or a repricing assumption; terms are read by counsel |
| Delivery capability | Release history, review practice, deployment access, evidence of shipped work of comparable size | A revision to the roadmap timeline, or a hiring plan and budget after close |
The most useful diligence outputs are rarely dramatic: what is owned, a credible number for what the system costs to run and improve over the hold period, and whether the roadmap is achievable with the team being acquired.
Common questions
- How is technical due diligence different from a code audit?
- A code audit assesses the condition of a codebase on its own terms and reaches the same conclusions regardless of who owns the company. Technical due diligence tests a system against a specific investment thesis, so the same finding can be immaterial in one deal and disqualifying in another. Diligence also covers ownership, key person risk, vendor contracts, and cost of ownership, which a code audit typically does not touch. The output is a set of recommended deal actions rather than an engineering backlog.
- How long does technical due diligence take and what does it cost?
- For a single-product company, two to four weeks with one or two senior engineers is a realistic window, and fees in the range of $20,000 to $60,000 are typical for that scope. Larger estates, multiple products, or a consolidation thesis push both numbers up. The constraint is usually the exclusivity period rather than the work itself, which is why the areas have to be worked in order of deal impact.
- What if the seller will not grant source code access?
- Limited access early in a process is normal, particularly with a competitor in the room. A staged approach works: architecture and vendor documentation first, then a supervised review session, then full repository access once the deal is closer to certain. If full access is still refused at the point of signing, that is itself a finding and should be reported as one.
- Which findings most often change the price?
- Quantifiable future spend changes the price most reliably, because it converts cleanly into a line in the model. End-of-life platform upgrades, a re-architecture needed to reach the volume in the growth case, and remediation capacity that will consume engineering time the roadmap assumed are the common ones. Findings about ownership and consent tend to become conditions of closing instead, since they are cheaper to resolve before the seller loses the incentive to help.
- Do we need lawyers involved in the technical work?
- Yes, for anything touching intellectual property assignment, open source licence obligations, data protection commitments, and change-of-control provisions in vendor contracts. The technical team produces the inventory and the factual record: who wrote what, which components are present, which vendors are material, and what stops working without them. Interpreting what an agreement or a licence requires is a legal judgment, and nothing in this guide is legal advice.
- What should a diligence report contain?
- A short summary aimed at the deal team, the material findings with a recommended outcome for each, an estimate of cost of ownership across the hold period, and the technical evidence in an appendix. Every finding should be labelled as a reason to walk, a price adjustment, a condition of closing, or first-hundred-days work. A report that lists risks without saying which of those four applies leaves the decision undone.