Blog
Key takeaways:
Somebody is going to read your code. Not skim the pitch deck, not nod along to the architecture diagram, actually clone the repo and look.
That moment tends to arrive at the worst time: a term sheet is signed, everyone is optimistic, and a reviewer you have never met is about to spend two weeks deciding whether your engineering is worth what your valuation says it is. Founders who have been through it once prepare very differently the second time.
This guide is written for the side being reviewed. It walks through what technical due diligence examines, the sequence it runs in, the checklist reviewers actually work from, the red flags that end deals, and the 90-day runway that turns a nervous audit into a short one.
Technical due diligence is an independent assessment of a company's technology, run on behalf of whoever is about to put money in. It answers one question in several parts: is this system what the founders say it is, and what will it cost to keep it running?
A quick disambiguation, because the phrase is overloaded. In commercial real estate, technical due diligence means a building survey: roof, HVAC, structural condition. In software, it means the codebase, the architecture, the infrastructure, the security posture, the intellectual property position and the engineering team. This guide covers the software kind.
The scope is wider than most founders expect. Reviewers care about the code, but they care at least as much about whether the code can be maintained by people who are not you. A brilliant system that only its author understands is a liability on a balance sheet, and experienced reviewers price it that way.
Software technical due diligence shows up at four moments: a priced funding round, an acquisition, a private equity buyout, and occasionally a large enterprise procurement where the buyer is betting its own operations on your uptime.
Who runs it varies more than the marketing suggests. A large private equity firm typically hires a specialist consultancy, while a growth fund often brings in an operating adviser or a fractional CTO from its own network. Early-stage investors frequently do very little, which is worth knowing because it shapes how much preparation is proportionate at your stage.
How hard a fund digs tracks its stage. Early-stage investors are mostly betting on the team and the market, while a growth fund is buying a system it expects to run for a decade.
One venture investor described their split on Reddit: a lightweight review before the term sheet, because the deal team are not engineers, then an external CTO brought in afterward to read the code, database, stack, roadmap and security, and to interview the technical leadership.
The two reviews sit on either side of the moment everyone treats as the finish.
The detail worth internalizing is the consequence they attached. If the founders had misrepresented the system, they covered the review costs and the round collapsed. If everything checked out, the same review became a funded action plan.
That is anecdotal, one firm's practice rather than an industry standard. It matches what we see, though: the deep review lands after you think the hard part is over.
The sequence is fairly consistent across reviewers, even when the depth is not. It runs on the same clock as the commercial track, so these stages interleave with the term sheet and closing steps of the venture capital process. Knowing the order lets you prepare for each stage instead of reacting to all of it at once.
Before a term sheet, the review is usually a conversation and a demo. Someone technical asks what the stack is, how many engineers you have, what breaks most often, and what you would rebuild given time. Nobody clones anything yet. The goal is to decide whether a deeper look is worth commissioning.
Once a deal is live, you receive a list. It is longer than you expect and it arrives with a deadline. Reviewers want architecture documentation, infrastructure inventory, security policies, incident history, the contributor list, contractor agreements, open source inventory and access to the repository itself.
This is the part founders worry about, and it is less about style than they fear. Reviewers run automated composition and vulnerability scanning across the repository, then read selectively: the oldest modules, the most-changed files, anything handling money or personal data, and whatever the architecture diagram claims is decoupled.
Reviewers talk to your CTO and usually two or three engineers, separately. They are checking whether the story is consistent, whether knowledge is distributed, and whether the people who built the system still work there. Contradictions between what leadership described and what the engineers say are the single most damaging thing that can happen in this stage.
You get a written assessment, normally graded by risk, with an estimate of what remediation costs and how long it takes. The report goes to the investor, not to you, though a fair reviewer will walk you through the findings. Its conclusions become negotiating positions.
Each stage feeds the next, so a weak document pack in stage two guarantees a slower, more suspicious stage three.
Reviewers work from a checklist, and there is no advantage in you not having seen it. The six areas below are near-universal, and the third column is what separates an answer that reassures from one that generates a follow-up.
| Area | What reviewers ask for | What a strong answer looks like |
|---|---|---|
| Codebase | Repository access, commit history, test coverage, dependency inventory | Consistent commit history across several engineers, tests that run in CI, a dependency list you generated yourself |
| Architecture | System diagram, data model, integration map, scaling history | A diagram that matches the code, plus a specific account of what broke at your last traffic peak |
| Infrastructure | Cloud accounts, environment inventory, deployment process, cost breakdown | Infrastructure defined in code, reproducible environments, a deploy that does not require one named person |
| Security | Policies, access controls, incident log, penetration test results, compliance status | A short incident history you volunteer rather than conceal, with what changed after each one |
| Intellectual property | Contributor agreements, contractor contracts, open source licenses, third-party code | Signed IP assignment from every contributor, including the freelancer from 2021 |
| Team | Org chart, tenure, on-call rotation, bus factor, hiring plan | More than one person who can deploy, and documentation written by someone other than the author of the code |
Work through that table honestly and you will already know which two rows will generate the awkward questions.
Open source is the fastest thing to audit and therefore the first thing reviewers scan. It is also where founders are most often surprised, because nobody chose those dependencies deliberately; they arrived as dependencies of dependencies.
The numbers here come from the one dataset built out of real audit work. Black Duck's Open Source Security and Risk Analysis report for 2026 draws on 947 audited codebases and 2,843 projects, audited for M&A transactions, regulatory compliance and internal risk assessment, with 197 M&A transactions represented in the set.
Open source turned up in 98% of them, at an average of 1,180 components per application, up 30% year over year.
Two findings matter most for a company preparing to be reviewed. Audited codebases carried an average of 581 vulnerabilities. And license conflicts appeared in roughly two-thirds of codebases, the highest rate in the report's history and a twelve-point jump in a single year, driven by dependencies pulled in indirectly.
The two findings differ less in size than in what happens to them afterwards.
Licensing is the one that actually derails transactions. A copyleft license buried four levels deep in your dependency tree can create an obligation to publish source code you consider proprietary, and unlike a vulnerability, a license obligation does not expire when you patch. Generate a software bill of materials before anyone asks for one, and read the license column.
Reviewers do not expect elegance. They expect the system to match its description and to have a plausible path to the next order of magnitude.
The gap they look for is between the diagram and the repository. An architecture described as service-oriented that turns out to share one database across every service is not automatically a problem, but describing it as decoupled when it is not costs you credibility on everything else you said.
The same three services, drawn as described and as built.
Scaling questions are usually concrete and historical rather than theoretical. What happened during your biggest traffic day? What is the slowest query in production and why has it not been fixed? Which component would fail first at ten times current load, and how do you know? Answers grounded in a real incident land far better than a capacity plan nobody has tested.
This is the part of a review where having built the system deliberately pays off. When we built the Nimbus platform for iCopy, a medical records retrieval company, the work started with a clickable prototype that doubled as a sales asset.
That sequencing meant the architecture got argued about before it was written rather than after. Client volume rose 300% and revenue grew tenfold within two years of launch, on a system somebody outside the company could actually read.
Security review is where an unprepared company loses the most time, because the questions are specific and the answers cannot be improvised.
Many reviewers now map findings to a published framework rather than a house checklist. The most common in US transactions is NIST's Secure Software Development Framework, SP 800-218, which organizes secure development into four practice groups: Prepare the Organization, Protect the Software, Produce Well-Secured Software, and Respond to Vulnerabilities. NIST's own framing is telling, since it describes the framework as a common vocabulary that purchasers can use to talk to suppliers during acquisitions.
The practical value for you is that it is public. You can audit yourself against the same four groups before anyone else does, and gaps you have already documented read as maturity rather than negligence.
Compliance obligations depend on what you touch. Health data means HIPAA, payment data means PCI DSS, European users mean GDPR, and enterprise buyers increasingly expect SOC 2. Reviewers do not always require a certificate, but they do require you to know which regime applies and to have a defensible answer about where you stand.
The list of regulated categories also keeps growing. We built Proceptual's platform for automated hiring compliance, a regime that barely existed five years ago.
The team assessment gets less attention in checklists than it deserves, because it is the finding that most often changes a valuation.
Reviewers are measuring concentration of knowledge. If one engineer is the only person who can deploy, the only person who understands billing, and the only person who has touched the database schema in two years, the acquirer is buying a dependency on an individual, not a system. That person is also the one most likely to leave after an acquisition.
Drawn out, the concentration is the whole finding.
Reviewers also look at how work moves. Is there a ticket trail? Do code reviews happen? Does anything reach production without a second pair of eyes?
None of this needs to be sophisticated. A small team with a simple, consistently followed process reviews far better than a larger team with an elaborate process nobody uses. It is the same standard we hold ourselves to on custom software development, where the deliverable is a system the client's own engineers can carry without us.
The uncomfortable question is usually about contractors. Every freelancer who committed code needs a signed agreement assigning that work to the company. Missing paperwork from four years ago is common, tedious to fix, and much cheaper to fix now than during a transaction.
Not every finding is equal. Some reduce the price, some delay the close, and a small number end the conversation. Sorting them this way is more useful than a flat list, because it tells you where to spend your remaining time.
| Red flag | What a reviewer reads into it | Severity |
|---|---|---|
| Credentials stored in plain text or committed to the repo | Nobody has been accountable for security | Deal-threatening |
| Copyleft licenses in proprietary code | A legal obligation the buyer inherits | Deal-threatening |
| Missing IP assignment from a past contributor | Ownership of the product is genuinely unclear | Deal-threatening |
| Founders describe the system differently from the engineers | Everything else you said needs re-checking | Deal-threatening |
| One person is the only one who can deploy | The asset is a person, not a system | Price-reducing |
| No automated tests on revenue-critical paths | Every future change carries unpriced risk | Price-reducing |
| Heavy technical debt with no remediation plan | Roadmap estimates are fiction | Price-reducing |
| Undocumented production incidents | You do not know your own reliability | Delay-causing |
| Sprawling cloud spend nobody owns | Margins are softer than the model shows | Delay-causing |
The pattern across the top four is not incompetence. It is a mismatch between the story and the system, and that is the only category on this list you cannot fix during a transaction.
Preparation works because most findings are ordinary. Here is the sequence we would run with a company expecting a raise or a sale in the next quarter, ordered so the slowest items start first.
Point eight is the one founders skip and reviewers value most. A known, documented, deliberately deferred gap is a decision. The same gap discovered by a reviewer is a surprise, and surprises are what get priced.
Knowledge concentration takes the longest to fix, so start it first. Pick the two systems only one person understands. Have that person pair with someone else through a real change to each, not a walkthrough, and let the second engineer write the documentation afterward. Documentation written by the person who already knows the system is the least useful kind, because it skips whatever they find obvious.
Cost and duration scale with deal size and with how prepared you are, and the second factor is the one you control. The figures below reflect the ranges we see in the US market for software transactions.
| Deal context | Typical depth | Elapsed time | Who pays |
|---|---|---|---|
| Seed round | Founder interview, demo, light stack review | A few days | Usually nobody, absorbed by the fund |
| Series A or B | External CTO, code scan, team interviews | 2 to 4 weeks | The investor |
| Private equity buyout | Specialist consultancy, full audit and remediation costing | 4 to 8 weeks | The buyer |
| Strategic acquisition | Full audit plus integration assessment | 6 to 12 weeks | The acquirer |
Two things shorten the elapsed time more than anything else: a complete document pack delivered on day one, and a technical leader who answers questions directly. Reviewers extend timelines when answers arrive slowly, because slow answers usually mean somebody is assembling something that should already exist. Founders who treat diligence as a discrete event rather than one stage in the arc from growth to exiting almost always start too late.
The report is not a verdict, it is an input to a negotiation, and founders who understand that do better in the weeks after it lands.
Findings typically translate into one of four outcomes: the price adjusts, money is held back in escrow against specific remediation, the deal closes with contractual commitments to fix named items on a schedule, or the buyer walks. The middle two are the most common by a wide margin.
Four ways this lands, and two of them account for almost all of it.
Ask to see the findings and respond to them in writing. A reviewer who states that your test coverage is thin has given you a fact; whether that fact is a two-week fix or a six-month rebuild is something you know and they are guessing at.
A specific, costed response frequently moves a finding from deal-threatening to a line in a remediation plan. It is also part of how you position a company to investors, because it shows the same command of detail they were testing for.
The companies that come through this well are rarely the ones with the cleanest code. They are the ones whose engineering leadership could explain, without hedging, what was solid, what was deferred, and what it would cost to close the gap. That is a description of a company that knows its own system, and it is the thing being bought.
If you are heading toward a raise or a sale and want an outside read on the codebase before an investor's reviewer gives you one, contact us. We have spent fourteen years building and inheriting systems in exactly this state, and we would rather tell you what a reviewer will find than have you hear it from them.
It is an audit of a company's technology, run by or for whoever is about to invest in it or buy it. A reviewer examines the codebase, architecture, infrastructure, security and engineering team, then reports on the risks and what fixing them would cost. It usually happens after a term sheet is signed and before money moves.
Financial due diligence verifies that the numbers are real: revenue, costs, contracts, cash. Technical due diligence verifies that the product behind those numbers is real and maintainable. They run in parallel and they inform each other, since a system with a two-year rebuild ahead of it changes what the financial model is worth.
Credentials committed to the repository, copyleft open source licenses inside proprietary code, and missing intellectual property assignment from past contributors are the three that most often threaten a deal outright. The fourth is a mismatch between how leadership describes the system and how the engineers describe it, which calls every other answer into question.
Start about 90 days out. Generate a software bill of materials and clear the license conflicts, collect signed IP agreements from everyone who has committed code, get secrets out of the repository, and write the architecture document against the system you actually have. Then audit yourself against the NIST SSDF practice groups and write down the gaps you are choosing not to close.
Expect concrete, historical ones rather than theoretical ones. What broke on your busiest day, and what did you change afterward? Which component fails first at ten times the load? Who besides your lead engineer can deploy to production? What is in your dependency tree that you did not choose? Answers grounded in real incidents are far more convincing than capacity plans nobody has tested.
Most of that runway is ordinary work that pays off whether or not a term sheet ever arrives: a bill of materials, signed IP assignments, secrets out of the repository, and an architecture document that matches the code as built.
If a raise or a sale is on your calendar and you want the gaps written down while there is still time to close them, contact us.
