A technical due diligence checklist covers what investors or acquirers examine before they commit: architecture, code quality, security, IP ownership, open-source licenses, infrastructure costs, team and key-person risk, and data protection. Behind every item sits one question: will this technology survive the growth we are paying for, and does the company actually own it?
It is rarely a pass-or-fail exam. It is a hunt for risks that could change the price, the terms or the timing of a deal, and almost everything on the list can be fixed or explained if you start early.
What is technical due diligence, and when does it happen?
Technical due diligence, often shortened to tech DD, is the part of an investment or acquisition review that looks at how your product is built, run and owned. It often happens after a term sheet or letter of intent is signed, when the investor is serious but has not yet committed the money. The depth depends on the deal:
| Deal | Typical depth | What to expect |
|---|---|---|
| Pre-seed and seed | Light | A call, a demo and a few pointed questions |
| Series A and later | Structured | Questionnaire, interviews, documents, often code access |
| Acquisition | Deep | Code and license scans, security review, team interviews |
The reviewer might be a technical partner at the fund, an outside specialist firm or an independent CTO hired for the job. Whoever it is, they will work from a list much like the one below.
The technical due diligence checklist
Work through this well before you raise. Each item is a statement you should be able to make truthfully, with evidence to back it up.
Architecture and scalability
- A one- or two-page architecture overview exists, with a simple diagram of the main parts and how data flows between them.
- You can explain why each major technology was chosen, and the stack is mainstream enough to hire for.
- You know your current load, your busiest periods and which component would struggle first at ten times today's usage.
Code quality and engineering process
- All code lives in version control, such as GitHub, under an organization account the company owns.
- A second person reviews changes before they reach production.
- Automated tests cover the critical paths, such as sign-up, payments and anything that touches sensitive data.
- Deployment is automated and repeatable, not a ritual one person remembers.
- A written list of known technical debt exists, with rough sizes and a plan.
Security
- Multi-factor authentication is on for every admin, cloud, code and email account.
- No passwords or API keys sit in the code; secrets live in a secrets manager and are changed when people leave.
- People only have the access their role needs, and former staff and contractors have been removed everywhere.
- Data is encrypted both in transit (as it travels between systems) and at rest (where it is stored, including backups).
- Backups run automatically, and someone has restored one recently to prove they work.
- Third-party packages are scanned for known vulnerabilities, and if you sell to larger customers, an independent penetration test (a hired, ethical attack on your product) is recent.
IP ownership and open-source licenses
- Every founder, employee, contractor and agency that wrote code has signed an IP assignment to the company, including work done before incorporation, because code ownership is not automatic.
- The company, not an agency or a former employee, owns the code repository, cloud accounts, domains and app store accounts.
- A report lists every open-source package you use and its license, and nothing is under terms that conflict with how you sell the product.
- Paid components, third-party code and any AI coding tools you used come with terms that allow commercial use.
Most open-source licenses are permissive and easy to live with. Some, known as copyleft licenses (GPL and AGPL are the best known), can require you to make your own source code available in certain situations, such as distributing the software or, for AGPL, letting users interact with it over a network. Because IP, licensing and data protection rules differ between countries, treat this checklist as general guidance rather than legal advice, and ask a qualified lawyer to check your assignments and any license questions.
Data protection and privacy
- A simple data map shows what personal data you collect, where it is stored, which vendors process it and who can access it.
- Your privacy policy matches what the product actually does.
- Data processing agreements are signed with every vendor that handles personal data, including AI providers.
- You know which rules apply to you, for example GDPR for users in the EU or the UAE's federal data protection law, and where your data physically lives.
- You can handle a user's request to see or delete their data, and you have a plan for reporting a breach.
Infrastructure and costs
- You can show monthly cloud and software spend for the last 12 months, broken down by main service.
- You know your rough infrastructure cost per customer and how it changes as you grow.
- Production, staging and development environments are separate, and production data is not copied onto laptops.
- Monitoring and alerts tell you about outages before customers do, and you can quote your recent uptime.
Team and key-person risk
- A current list shows everyone who works on the product, employed or contracted, with their role and what they own.
- No critical system is understood by only one person, or there is a written plan to fix that.
- Key engineers have reasons to stay, such as vesting equity, and contractor agreements include handover duties.
- A credible hiring plan exists for the roles the new money will fund.
Documentation
- A new developer could set up the project and ship a small change in their first week using the written docs.
- Major technical decisions are recorded with the reasons behind them.
- Short runbooks cover common emergencies: the site is down, a deploy failed, a key leaked.
Red flags that change deals
Reviewers expect some mess. Every startup carries shortcuts and technical debt, and nobody marks you down for code that is merely imperfect. These are the findings that move valuations, add conditions or stall a close:
- Accounts the company does not control. The repository, cloud or app store account sits with an agency, a freelancer or a departed co-founder.
- Missing IP assignments, especially from early contractors and from founders' work before the company existed.
- Copyleft code in a product that cannot meet the license terms.
- Secrets in the code or shared passwords, which suggest security is an afterthought.
- Backups that have never been restored. An untested backup is a hope, not a plan.
- One person who knows everything, with no documentation and no plan if they leave.
- Costs growing faster than customers, which raises questions about your unit economics.
- Claims that do not match the code. If the deck says proprietary AI and the code is a thin layer over a third-party model, the reviewer is likely to notice. Using a hosted model is fine; describing it accurately is not optional.
If your product has AI features, expect questions about what data you send to providers and how you measure quality; my guide to adding AI features without burning money covers both.
Rule of thumb: disclose known problems before the reviewer finds them, with a plan and a date attached. Reviewers forgive technical debt. They do not forgive surprises.
How to prepare a data room for tech due diligence
A data room is a shared, access-controlled folder holding everything a reviewer needs. A tidy technical section answers many questions before anyone asks them. Include:
- The architecture overview and diagram.
- A list of the stack and every third-party service, with the data each one touches.
- Twelve months of infrastructure and tooling costs.
- A security summary: policies, access controls, the latest penetration test if you have one, and a log of past incidents and how each was handled.
- The open-source license and vulnerability report.
- Copies of IP assignment agreements and contractor contracts.
- Data protection documents: the data map, privacy policy and vendor agreements.
- A team overview, including contractors, showing who owns which system.
- The product roadmap, plus your known technical debt list and the plan for it.
- Basic delivery and reliability numbers: how often you release, uptime and recent incidents.
For the code itself, offer read-only, time-limited access to the repository once an NDA is signed, or a guided walkthrough on a screen share if you would rather not hand it over. Name one person as the technical point of contact, so answers stay consistent.
How long does technical due diligence take?
The review itself often takes one to a few weeks for a venture round once the documents are ready, and longer for an acquisition. Preparation is the variable part. From a standing start, give yourself six to eight weeks of part-time work, because the slowest fixes depend on other people: a former contractor who must sign an IP assignment, or an agency that must hand back an account (here is how to get code and accounts back from an agency).
A realistic plan looks like this:
- Eight weeks out: audit who owns every account, check IP assignments and start chasing signatures.
- Six weeks out: run the license and vulnerability scan, switch on multi-factor authentication everywhere, remove old access and test a backup restore.
- Four weeks out: write the architecture overview, the data map and the technical debt list.
- Two weeks out: assemble the data room and do a mock review with someone technical who has not seen the product before.
Where a fractional CTO fits
If you already have a strong CTO or tech lead, they should own this process, and an outside code audit may be the only extra help you need. If you do not, due diligence exposes the gap quickly: reviewers want to know who is accountable for the technology, and “our agency handles it” is a weak answer.
A fractional CTO can run the mock review, fix the urgent issues, write the documents, sit in on reviewer interviews and stay on afterward to deliver the plan the investors funded. A raise on the horizon is one of the clearest signs it is time to bring one in, ideally months before the term sheet rather than days after it. If you are weighing that route, here is how my fractional CTO engagements run.
The bottom line
Technical due diligence rewards founders who look first. Work through the checklist well before you raise, fix ownership and security gaps early because they take longest, write down what you know is imperfect, and put it all in a tidy data room. You do not need perfect code. You need to own what you built, know its weak points and show a credible plan for them.
Frequently asked questions
How much does technical due diligence cost?
For the startup being reviewed, the main cost is time: founders and engineers answering questions and preparing documents. The investor or acquirer usually pays for its own reviewer. If you commission an independent pre-diligence review to find problems first, the price varies widely with product size and depth, typically from a few thousand dollars for a focused review to considerably more for a deep code and security audit.
Can a startup fail technical due diligence?
Rarely in one dramatic moment. More often the findings change the deal: a lower valuation, conditions to fix before closing such as signing IP assignments or moving accounts, money held back until issues are resolved, or a delayed close. Deals do fall apart when the review shows the product cannot do what was claimed, or that the company does not actually own its code and accounts.
What is the difference between technical due diligence and a code audit?
A code audit looks only at the code: its structure, quality, test coverage and security flaws. Technical due diligence is broader. It also covers architecture, infrastructure and costs, IP ownership and licenses, data protection, the team and key-person risk, and how the product is built and operated day to day. A code audit is often one input into a technical due diligence review.
Do seed-stage startups need to prepare for technical due diligence?
Lightly, yes. Seed investors rarely run a full technical review, but they may ask who built the product, whether the company owns the code and how it will cope with growth. Signed IP assignments, accounts in the company's name and a one-page architecture overview cost little to put in place, and they make the deeper reviews at Series A or in an acquisition far easier.
What security certifications do investors expect from startups?
Usually none at the early stages. Investors care more that the basics are in place: multi-factor authentication, controlled access, encrypted data, tested backups and a record of incidents. Formal certifications and audits, such as ISO 27001 or a SOC 2 report, tend to become relevant when enterprise customers ask for them, and later-stage investors may then want to know how far along you are.