Technical due diligence has a reputation it does not deserve. Founders picture a stranger reading their code and marking it out of ten for elegance. That is rarely the job. Whoever does the review, whether they work for a fund, for an acquirer or for a firm hired by either, is trying to answer three plain questions about the thing being bought:
- What breaks when this grows?
- What breaks when someone attacks it?
- What breaks when one person quits?
Nearly everything on a due diligence questionnaire is a variation on those three. A monolith is not a finding. A monolith that falls over at twice today's traffic, whose deploy script lives on the CTO's laptop, is.
I have built products from both ends of this: as the founding engineer who took TRIBE from nothing to 100,000 users with three developers, and as the only engineer on EMPRO, a platform designed from the first week to be handed over and run by someone else. The architecture reviews I do now cover the same ground a technical due diligence does. This post is the checklist, a scorecard you can run on yourself in ten minutes, and an honest view of which findings matter and which ones a reviewer will simply note and move past.
What a reviewer is actually testing
The depth varies with the deal. For an early round it may be a questionnaire, a call with whoever runs engineering and a look at the repository. For an acquisition, where the buyer is paying for the code and the people who understand it, it can run to weeks of code reading, security testing, licence scans and interviews. The questions stay the same. What changes is how much evidence you are asked to show.
It helps to think of every item as one of three kinds of break, laid across the six areas a review usually covers.
The growth column is about headroom: which part saturates first, and whether anyone has checked. The attack column is about ordinary attacks, not film plots. Stolen passwords, leaked keys and one customer reading another's data account for far more damage than anything clever. The third column is the one founders underestimate. A study of 133 popular open-source projects found that 65% had a truck factor of two or fewer, meaning two departures would leave a large part of the code with nobody who knows it. Those projects are public, popular and have many contributors. A five-person startup has no particular reason to do better, and usually nobody has measured it.
The checklist, area by area
Twenty questions in six areas. Each is phrased so that "yes" is the answer a reviewer hopes for, and each carries a weight for how badly a "no" hurts. The evidence matters as much as the answer. "Yes, here is the restore log from July" is worth more than "yes, I think so".
Architecture: headroom and moving parts
Has anyone tested the system at several times today's peak? Is there a current one-page diagram and a list of every third-party service on the request path? Do slow or flaky calls such as email, webhooks, payment callbacks and AI APIs run in a queue with retries rather than inside the web request?
None of these asks for microservices. A well-structured monolith is often the right shape for a young company, and splitting too early is a more common problem than not splitting at all. What a reviewer wants is evidence that somebody has asked where it breaks. The dependency list matters because every service on the request path multiplies into your uptime, which is the arithmetic behind composite SLAs. Queues with retries only help if running a job twice does no harm, so expect a follow-up question about idempotency.
Security: the attacks that actually happen
Verizon's 2025 Data Breach Investigations Report, which is vendor research but analysed 12,195 confirmed breaches, found that credential abuse (22%) and exploited vulnerabilities (20%) were the leading ways in, and that third-party involvement had doubled to 30%. That maps to four questions: is MFA enforced for everyone on the cloud console, code host, domain registrar and company email; are secrets out of the code; is access control enforced on the server with tests for tenant isolation; and are dependencies patched on a schedule, with an outside test in the last year?
Tenant isolation deserves its own sentence. The first item in the OWASP Top 10:2025 is broken access control, and in a multi-tenant product that means customer A can see customer B's data by changing an ID in a URL. It is the finding most likely to turn a routine review into a hard conversation, and it is cheap to test for.
On secrets, the question is not whether the keys are in a .env file today. It is whether they are anywhere in the git history. GitGuardian, which sells secret scanning and should be read as vendor research, counted 28.65 million new hardcoded secrets pushed to public GitHub in 2025, found that more than 64% of credentials confirmed valid in 2022 were still valid when retested in January 2026, and reports that internal repositories are roughly six times more likely than public ones to contain them. A key that was committed once and deleted later is still in the history, and still works until someone rotates it.
Data: backups you have restored
Are backups automatic, stored outside the production account, and restored successfully in the last 90 days? Do you know where personal data lives and who can reach it, and can you export or delete one person's data on request? Are schema changes made through versioned migrations rather than by hand?
A backup nobody has restored is a hope, not a control. Keeping it outside the production account matters because the same Verizon report found ransomware in 44% of breaches, and an attacker who holds your cloud account holds any backup stored inside it. The personal data question is about the privacy law in the markets you sell to; a reviewer does not need you to be perfect, but they need you to know where the data is.
Delivery: how changes reach production
Does every change pass automated tests in CI? Can you deploy on any working day and roll back within minutes? Do alerts reach a person when customers are affected, and is there a written record of recent incidents?
The shared vocabulary here comes from DORA, whose software delivery metrics are change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate. You will rarely be asked for all five, but you will be asked how often you deploy and what happens when a deploy goes wrong. At TRIBE, putting automated test pipelines in place cut our bug reports by around 70%, and that kind of before-and-after number is exactly what a reviewer likes to see. For monitoring, alert on what customers feel rather than on CPU; logging everything is not the same as being able to explain an incident.
People and bus factor
Could the product be shipped and operated for a month if your most senior engineer left tomorrow? Does the company, rather than a person or an agency, own the repository, cloud accounts, domains and app store listings, with intellectual property assigned by everyone who wrote code? Could a new engineer ship a small change in their first week from what is written down? Is every change reviewed by someone other than its author?
The ownership question is the one that surprises founders. If the first version was built by a freelancer or an agency, the buyer will want to see that the IP was assigned to the company, and if the AWS root account is registered to a former employee's personal email, that is a problem for the lawyers as well as the engineers. On documentation, my own lesson from EMPRO is to write handover notes from week one. Writing them at the end meant documenting decisions I had already forgotten the reasons for.
Cost: the infrastructure unit economics
Do you know what infrastructure and third-party APIs cost per customer, and how that changes as you grow? Are there budget alerts on usage-priced accounts? Could you leave your most expensive vendor within a quarter if its price doubled?
This area matters more than it used to because so many products now carry a usage-priced AI bill, where cost per user can grow faster than revenue if nobody is watching it. A budget alert also doubles as a security control: a leaked API key usually shows up as a bill before it shows up anywhere else.
Score yourself
Answer honestly, including "don't know", which counts as a no because that is how a reviewer reads it. The defaults describe an invented but ordinary-looking seed-stage company: good delivery habits, MFA in place, a senior engineer who holds too much, and no idea what a customer costs to serve.
self-assessment · 20 questions, weighted by what a "no" costs
Score your company before a reviewer does
Architecture
Security
Data
Delivery
People and bus factor
Cost
by area · green 75+, amber 45 to 74, red under 45
fix these first
Yes scores 2, partly 1, and no or don't know 0, multiplied by the question's weight. Weight 3 marks the questions where a single gap can stop a deal or lose data, and a zero on any of them caps its area at amber. The fix list is ordered by points lost. This is a way to find your own gaps, not a standard any investor uses.
With the defaults, that company scores 63 out of 100. Delivery is green, cost is red and the other four areas are amber. The top of the fix list is the bus factor, followed by cost per customer, then secrets in the history, tenant isolation and backups. That ordering is the point of the tool. It is tempting to spend the weeks before a raise polishing whatever you are proudest of. The list tells you where the points are actually being lost.
The weights are my judgement, not an industry standard, and a buyer in a regulated sector will weight security and data more heavily than I have. Treat the score as a way to find your own gaps, not as a grade anyone else will use.
Evidence to have ready
Reviewers ask for evidence, and producing it for the first time takes longer than founders expect. This is what each area usually comes down to:
| Area | What to be able to show | What a red usually looks like |
|---|---|---|
| Architecture | one-page diagram, dependency list with SLAs, last load test | nobody knows the first thing to break |
| Security | MFA status from each admin console, secret scan output, last outside test | shared logins, keys in the git history |
| Data | restore log with date and duration, personal data inventory | backups never restored, or stored next to production |
| Delivery | deploys in the last quarter, incident notes | deploys from a laptop, no record of incidents |
| People | account ownership list, IP assignments, who can deploy | one person holds every credential |
| Cost | monthly bill by service, cost per active customer | no idea, or a bill growing faster than revenue |
quick check
A reviewer finds four things. Which is most likely to hold up the deal rather than simply be noted?
The other three are ordinary engineering debt that a buyer can estimate and price. Unassigned IP goes to what is actually being bought, and fixing it depends on a third party signing something, which you do not control.
What reviewers note, and what they chase
Founders often spend their preparation time on the wrong column. Here is how the common findings tend to split. It is a tendency, not a rule, and a buyer with particular plans for the product will have particular worries.
| Usually noted and priced | Usually needs an answer before signing |
|---|---|
| A monolith | Code or accounts owned by an agency or a former contractor |
| An old but supported framework | One customer able to read another's data |
| Thin tests outside the money paths | Backups that have never been restored |
| A manual step in the deploy | Live secrets in the git history |
| Technical debt the team can name | Technical debt nobody can name |
| No Kubernetes | One engineer who holds every credential |
The right-hand column has something in common: each item is a risk that nobody on your side can put a size on. That is what makes a reviewer slow down. A known problem with a plan attached reads very differently from the same problem discovered by the reviewer.
The weeks before the data room
If a raise or a sale is coming, this is the order I would work in, cheapest and most consequential first:
- Accounts and MFA. Move every account to company-owned email with at least two admins, and enforce MFA on the cloud console, code host, registrar and email. This is days of work, not weeks.
- Secrets. Scan the full git history, rotate everything you find, and move the rest into a secret manager.
- A timed restore. Restore last night's backup into a clean environment and write down how long it took.
- Tenant isolation tests. Try to read another account's data through every route. Fix what works.
- The one-page architecture. A diagram, the dependency list and the known limits, written by the person who knows them.
- A second person on everything. Deploys, on-call and the riskiest module, until someone other than the senior engineer has done each one alone.
- Cost per customer. One number, with how it was calculated.
What not to do: start a rewrite or a migration to microservices so the architecture looks modern. A half-finished migration is harder to explain than the system it was meant to replace, and it moves the risk into exactly the areas a reviewer is looking at. If a migration is already under way, be ready to say which parts are done, which are not, and how the two halves talk to each other.
questions people ask
What is technical due diligence?
It is the part of an investment or acquisition review that looks at the technology: architecture, security, data handling, how software is delivered, who holds the knowledge, and what it costs to run. The aim is to find what would break under growth, under attack or when key people leave.
What do investors look at in technical due diligence?
Usually architecture and scalability, security controls such as MFA and secret handling, backups and personal data, the delivery process, key-person risk and IP ownership, and infrastructure cost. Early rounds go lighter; acquisitions go deeper, often including code review and licence scans.
How long does technical due diligence take?
Anything from a single call for an early round to several weeks for an acquisition. Preparation is what takes the time, because evidence such as restore logs, account ownership lists and incident notes takes days to produce if nobody has produced it before.
What are red flags in technical due diligence?
Unassigned IP or accounts owned by a contractor, customer data readable across accounts, backups that have never been restored, live secrets in the code history, and a single engineer who holds every credential. Ordinary technical debt is rarely a red flag on its own.
Does a monolith fail technical due diligence?
No. A well-structured monolith is a normal and often sensible architecture for a young company. What matters is whether you know its limits, have tested them, and can explain how it would grow.
How do I prepare for technical due diligence?
Start with company ownership of every account and MFA everywhere, then rotate any secrets in the git history, do a timed backup restore, test tenant isolation, and write a one-page architecture with its known limits. Avoid starting big rewrites just before a review.
The short version
A technical due diligence review is not a code beauty contest. It asks what breaks when the company grows, when someone attacks it, and when one person leaves, across architecture, security, data, delivery, people and cost.
Reviewers can price the debt you can name. What slows a deal is what nobody can put a size on: accounts owned by the wrong person, data one customer can see from another's account, backups that have never been restored, secrets in the history, and a single engineer holding everything. Most of those are cheap to fix and quick to evidence. Fix them first, write down what you did, and leave the rewrite for after the money is in the bank.