Technical Due Diligence: What an Audit Covers

Technical due diligence is an outside review of a company’s code, infrastructure, security and team, done before money or ownership changes hands. Investors order it before a round, acquirers before signing, and sensible founders order it on themselves before they scale.

Our senior team in Ahmedabad runs a two-week codebase audit before any scaling work, so we sit on the inspecting side of this process. If you are about to audit a codebase before scaling it, most of the questions are the ones a buyer’s reviewer will ask. We read the code, the data model, the infrastructure and the cloud bill, then write down what we found, ranked by what it costs. Below is what a review inspects, how we grade findings, what the buyer receives and how a seller can prepare.

When technical due diligence happens

The trigger changes the depth, not the method. A buyer about to sign wants more than a founder checking their own work, but both are asking whether the product is what the pitch says it is.

One case sits outside the table. When a project is already failing, with missed releases and a team that cannot say why, you need a recovery plan rather than a review. We cover that in how to rescue a failing software project.

What a technical due diligence audit inspects

A review works through seven areas. The checklists we read while preparing this post use much the same headings, so the useful part is what gets measured under each one.

Architecture and the load it can carry

We start with a diagram of the system as it runs today, not as the pitch deck draws it. After that come the data model, how tenants are separated, where state lives and which single points of failure exist. One database host with no replica is a finding. So is a queue that only one process can drain.

Underneath sits a plain question: what breaks at ten times today’s traffic or customer count? In the products we review, the answer is seldom the clever part. Instead it tends to be a query without an index, a report that locks a table while it runs, or one tenant whose data volume dwarfs everyone else’s. Problems like these can usually be fixed without a rewrite, so the report should say which ones are of that kind.

Code quality and test coverage

First, we build the project from a clean checkout. If that takes a day of questions to the original developer, we have learned something before reading a line of code. Then we look at structure, naming, duplication and how far the code has drifted from its own conventions.

Tests get the same treatment. A high headline coverage figure tells us little when the billing path has none, so we check coverage on the paths that lose money when they fail: sign-up, payments, permissions and data export.

Technical debt is not a verdict by itself, but it has a running cost. For example, in Stripe’s Developer Coefficient survey of September 2018, developers estimated that 17.3 hours of a 41.1-hour working week went on maintenance: bad code and errors, debugging, refactoring and modifying. That figure is self-reported, but it gives a sense of the drag a buyer is pricing.

Dependencies, licences and the SBOM

A software bill of materials, or SBOM, is a machine-readable list of the components inside a product. The NTIA’s minimum elements report of July 2021 names seven data fields: supplier name, component name, version, other unique identifiers, dependency relationship, author of the SBOM data and a timestamp.

Governments have started asking for them. Executive Order 14028, signed on 12 May 2021, directed NIST to issue guidance on securing the software supply chain, and it listed providing a purchaser an SBOM for each product among the practices that guidance should cover. That order is aimed at software the US federal government buys; it does not by itself oblige a private buyer or seller to produce one. The EU’s Cyber Resilience Act (Regulation (EU) 2024/2847) goes further. It entered into force on 10 December 2024, and its reporting obligations have applied since 11 September 2026. Once the main obligations apply on 11 December 2027, manufacturers of products with digital elements must draw up an SBOM covering at least the top-level dependencies.

Which licences carry deal risk

In a deal, though, the SBOM matters most because it feeds the licence inventory. Licences fall into families, and each family carries a different risk for a SaaS product:

AGPL is the row we look at first. A single modified AGPL component inside a hosted product can force a choice between publishing your changes and replacing the component, and a buyer will price that replacement. Whether a particular use triggers the clause is a legal question, so take it to counsel. The audit’s job is to find the component and show where it sits.

Security

We begin with the mistakes we would least want a buyer to find. Secrets committed to the repository, including ones deleted later but still in the history. Access control that checks the login but not who owns the record. Dependencies with known vulnerabilities. Logs too thin to reconstruct an incident from.

The OWASP Top 10:2025 is a fair guide to what else to check. It puts Broken Access Control first and Software Supply Chain Failures third (A03). The supply chain risk is real, too: Sonatype’s 2026 report says it identified more than 454,600 new malicious packages during 2025.

Log4Shell makes a good test case. Apache rated CVE-2021-44228 at CVSS 10.0, the maximum. So the reviewer’s question is not whether you were hit. It is whether, within an hour, someone could say whether you ship that library version and where. With a current SBOM, that answer comes from a file. Without one, somebody starts searching repositories and build images by hand.

Infrastructure and cloud cost

Here we count the environments and check whether they match, whether infrastructure is defined in code or clicked together in a console, and when a backup was last restored. If the honest answer to that last one is “never”, nobody actually knows whether the backups work.

Next comes the bill. Set a cloud invoice against actual usage and it shows services paid for out of habit, oversized databases and test environments nobody switched off. We pay the hosting bills for four of our own SaaS products, so we read invoices the way an owner does. Our post on cloud-first infrastructure for startups covers the design side.

Delivery process

How does code reach production? To find out, we trace one change from commit to live. Along the way we look for code review, automated checks on every merge, a way to roll back, and a release rhythm the team can keep up. Incident history, however, says more than any process document. Ask when production last broke, how long recovery took and what changed afterwards.

The bus factor and documentation

The bus factor, or truck factor, counts how many people would have to leave before a project stalls. Avelino and colleagues estimated it for 133 popular GitHub projects in a 2016 paper and found that 65% had a truck factor of two or less. Those were open-source projects, so a private codebase has to be measured directly.

That is why we ask who can deploy, who understands billing, and who holds the DNS and cloud root accounts. Then we test the documentation bluntly: could a new engineer run the product locally from the README alone? If not, the knowledge lives in someone’s head, and the buyer is acquiring that head as well.

How technical due diligence findings are graded

Every finding in the report gets one of four grades. This is our scheme, not an industry standard, but it follows what a deal can actually do with a problem.

Each finding also carries the evidence and a remediation estimate in engineer-weeks. Of the three, evidence matters most. “Security is weak” is an opinion, whereas “the production database password sits in this commit, on this date” is something the other side can check in a minute.

Grades keep the conversation honest as well. Hand a buyer forty unranked findings and all forty become leverage. Rank them, and both sides end up arguing about the three that count.

What the buyer or investor receives

A technical due diligence report is a written document rather than a slide of traffic lights. A useful one has these parts:

• A one-page summary with a verdict a non-engineer can act on.
• The risk register: every finding with its evidence, grade and effort estimate.
• The SBOM and licence inventory, with anything copyleft flagged.
• The architecture diagram as it is, with the weak points marked.
• The total cost of remediation, split by grade.
• A list of questions for management that the code could not answer.

After that, the grades decide the next step. Critical items go back to the seller to fix or explain. High items tend to become a lower price, a holdback released once the fix is verified, or a warranty covering a named risk. Medium items turn into the first quarter of the engineering plan. Counsel drafts the contract wording, while the report supplies the facts it rests on.

Preparing your company for technical due diligence

Preparation will not hide a problem, and it should not try to. What it buys you is the chance to explain each problem before a reviewer finds it. Most of this list is days of work, not months:

• Generate your own SBOM and run a licence scan, so you meet any AGPL surprise first.
• Rotate every secret that was ever committed, even if the file was later deleted.
• Build the product from a clean checkout on a fresh machine and note every step that failed.
• Restore a backup into a scratch environment and time it.
• Write down who can deploy, who holds each cloud and DNS account, and who covers for each of them during a holiday.
• List your known debt with rough effort. A short, true list earns more trust than a clean one a reviewer disproves in a day.
• Pull the cloud bill by service for the last six months, and be ready to explain the spikes.

How long technical due diligence takes

Our pre-scaling audit takes two weeks. A buyer’s review of a product with many repositories, many services or a regulated data set can run longer, so agree the scope before the clock starts.

Access is the delay you can control. Repository, cloud console, monitoring and the bill should all be ready on day one, because when read-only access arrives on day six, the two weeks start on day six too.

If you are the seller, run the preparation list above before anyone asks. If you are the founder about to hire for growth, the same review tells you which three problems to fix first. Better to hear that from your own audit than from a buyer’s.