Technical Due Diligence: What We Check (Full Checklist)
Technical due diligence is the part of a deal where somebody finally reads the code. Whether you are an investor about to wire money, an acquirer about to inherit a platform, or a founder about to be on the receiving end, this guide lists what a technical due diligence review actually checks, area by area, what counts as a red flag, and what the report at the end should look like.
Key takeaways
- Technical due diligence (also called technology due diligence or tech DD) answers three questions for a buyer or investor: what are we getting, what will it cost to keep, and what has to be fixed before it is safe.
- Seven areas cover almost every review: architecture, code quality and technical debt, security, infrastructure and DevOps, data, team and process, and intellectual property, licences and open source.
- The most expensive findings are rarely in the code itself. They are in access (who holds the keys), in data (what is stored where and under which law) and in people (who is the only person who understands the core).
- A useful report ranks findings by business risk, worst first, and puts a plan next to each one. A list of every lint warning is not due diligence.
- Company-side (sell-side) due diligence is the same checklist run early by the company itself, so the buyer finds a fix log instead of a surprise.
- A code audit is narrower than due diligence: it looks at one codebase for defects. Due diligence looks at the whole technology function and what it means for the deal.
What is technical due diligence?
Technical due diligence (technology due diligence, tech DD) is an independent review of a software company's technology before an investment, acquisition or vendor takeover. It examines architecture, code quality, security, infrastructure, data, team and intellectual property to tell the buyer what they are getting, what it costs to run and grow, and which risks must be fixed before closing.
It sits alongside financial, legal and commercial due diligence, and it borrows from each of them. The legal team wants to know who owns the code and which open source licences it carries. The finance team wants to know whether the cloud bill and the engineering headcount in the model are realistic. The commercial team wants to know whether the roadmap the founders are pitching can be built on what exists. Technical due diligence is where those questions get answered by someone who has opened the repository.
The word "independent" matters. The people who built the system have a view of it, and that view is usually honest, but it is not neutral. A reviewer who does not profit from the outcome, and who is not going to be hired to do the rebuild, is the only one whose "keep it" or "walk away" carries weight.
When technical due diligence is needed
Three situations account for most reviews, and a fourth is becoming common.
Pre-investment (seed to growth rounds)
An investor is pricing a company whose main asset is software. At seed the review is light and mostly about whether the product is real and whether the founders can build. By Series A and beyond it is a proper exercise: can the platform carry the growth in the model, how much of the next round goes into paying down technical debt, and is there anything that would embarrass the fund later.
Mergers and acquisitions
An acquirer will own the system, the team and every liability inside them. The questions go further than "is it good": can it be integrated with ours, which parts are worth keeping, what does it cost to run, and what happens if the two engineers who understand it leave at closing. Private equity funds run this on every platform and add-on deal, and the findings go straight into the price and the 100-day plan.
Vendor takeover and handover
A company is taking a product back from an agency or outsourcer, or moving it to a new one. There is no price to negotiate, but the same review tells the new owner what they are inheriting, whether the repositories, cloud accounts and pipelines are actually under their control, and what the first 30 days of ownership should fix.
Preparing to raise, as the company
Founders increasingly run the review on themselves before a round. With AI coding tools in the mix, a growing share of early-stage products have never been read by a senior engineer, and an investor's reviewer will be the first. Running the checklist first means that reviewer finds a fix log rather than a surprise. For AI-built apps specifically, the vibe coding cleanup audit is built for exactly this moment.
The technical due diligence checklist, area by area
The seven areas below cover almost every review. For each one the table gives the question the buyer is really asking, and the sections after it list what to look at and what counts as a red flag. The depth per area depends on the deal: an acquirer integrating a platform spends more time on architecture and data; a seed investor spends more time on team and security basics.
1. Architecture
What to look at. Start from a diagram, then check that the code matches it. Where are the service boundaries and are they real or just folders? How does the system scale: by adding instances, by sharding, or not at all? What are the single points of failure? How is the data model shaped, and does it reflect how the business actually works (tenants, accounts, orders) or how the first developer happened to think? For an acquisition, add integration: which APIs exist, how are they versioned, what would it take to connect this to the buyer's identity, billing and reporting?
Red flags. No diagram anyone can draw from memory. One database shared by everything with no clear ownership. A "microservices" layout where every service calls every other one synchronously. Scaling claims with no load test or production metric behind them. Core business logic living in the database, in spreadsheets, or in a founder's head.
2. Code quality and technical debt
What to look at. A reviewer reads the code, not just the metrics. The questions: is it consistent enough that a new engineer can work in it, is it tested where it matters (money, access, data integrity), how old are the dependencies and how far behind is the runtime, and how much of the bug backlog is the same problem reappearing? Technical debt is not a problem in itself; every real system carries some. The question is whether it is known, written down and priced. Our earlier piece on why technical debt belongs in the boardroom covers how to put a number on it.
Red flags. No tests around payments or permissions. A framework or language version that stopped receiving security updates. Large modules nobody is willing to touch. Duplicate implementations of the same logic with slightly different behaviour. For AI-built products, the debt has a recognisable shape, which we describe in our guide to technical debt in AI-built apps: inconsistent patterns, copy-paste duplication at scale and missing operational scaffolding.
3. Security
What to look at. Authentication and authorisation first: how users sign in, how roles are enforced, and whether every endpoint actually checks. Then secrets: where API keys, database passwords and signing keys live, who can read them, when they were last rotated. Then the history: past incidents, bug bounty or pen test reports, and what was done about them. Compliance evidence (SOC 2, ISO 27001, GDPR controls) is read as a signal, not a guarantee. The OWASP Application Security Verification Standard is a reasonable public yardstick for the application layer.
Red flags. Credentials committed to the repository, especially ones still valid in production. Endpoints that trust the client, so anyone who finds the URL can read or change data. Former contractors who still have access. "We have never had an incident" with no monitoring that could have detected one. In the composite sample verdict on our Fractional CTO page, the three findings marked "fix before launch" are all of this kind: payment endpoints with no authentication, webhook handlers that were stubs, and API keys in the repository that every past contributor still held.
4. Infrastructure and DevOps
What to look at. How a change gets from a developer's laptop to production, and how a bad change gets rolled back. Whether the infrastructure is described in code or clicked together in a console. Monitoring and alerting: would the team know about an outage before the customers do? Backups: do they exist, have they ever been restored, and where do they live? And the bill: what does it cost to run per month, how does it move with usage, and is anyone looking at it?
Red flags. Deployments done by hand by one person. No staging environment, or one that looks nothing like production. Backups that have never been restored. Cloud accounts registered to a personal email. Database migrations that have drifted from what is actually running in production, so the next deploy may fail or silently drop data.
5. Data
What to look at. An inventory: what personal, financial or health data is stored, in which systems, in which regions, and for how long. Who can query production data and whether that access is logged. How data gets into analytics, AI models and third-party tools, and whether customers agreed to that. For an acquisition, migration: can the data be moved into the buyer's systems, and is the schema clean enough to make that a project rather than a rescue?
Red flags. Production data copied into developer laptops or test environments. Personal data of EU users stored outside the EU with no transfer basis. No retention policy, so nothing is ever deleted. Customer data sent to an AI provider under a consumer plan. Reporting numbers that cannot be reconciled with the database.
6. Team and process
What to look at. Who actually writes the code, and the commit history is a better answer than the org chart. How concentrated the knowledge is: how many people could ship a fix to the billing system on a Saturday? How work is planned, reviewed and released. Whether the engineering budget in the deal model matches the cadence the team has shown. For founder-led or AI-assisted builds, whether a senior engineer has ever read the whole thing, and how the developers work with AI tools today.
Red flags. One engineer with more than half of all commits and no documentation. Releases that keep slipping with no written reason. No code review, or review by the same person who wrote it. Key engineers on short contracts with no retention plan. A vendor relationship where the client cannot read the work they are signing off.
7. Intellectual property, licences and open source
What to look at. Whether every contributor, including freelancers, agencies and former co-founders, has assigned their work to the company in writing. A software bill of materials: every open source dependency and its licence, checked against the SPDX licence list or a licence scanner. Any copyleft licence (GPL, AGPL) in a product that is distributed or offered as a service. Third-party components, models or datasets with terms that restrict commercial use. Trademarks and domains, and who registered them.
Red flags. Code written by an agency under a contract that never mentions ownership. AGPL libraries inside a SaaS backend with no plan for it. Dependencies pulled from personal GitHub accounts. A core model or dataset whose licence forbids the use the company is making of it.
How the process runs and what the deliverable looks like
In practice a technical due diligence review follows a fairly standard sequence, whoever runs it:
- Scoping. The buyer and the reviewer agree what matters for this deal: an integration-heavy acquisition needs a different emphasis from a seed cheque.
- Request list. The company receives a list of documents and access requests: architecture diagrams, repositories, infrastructure accounts, security reports, contracts, team information.
- Management interviews. The reviewer talks to the CTO, lead engineers and often the product lead, and compares what they say with what the code and the systems show.
- Review. Reading the code, inspecting the infrastructure, checking access and running whatever scans and checks the scope calls for.
- Report and debrief. Findings ranked by risk, their likely cost, and a recommendation.
What the report should contain is where reviews differ most, so here is what ours contains. The technical diagnostic run by Valletta's Fractional CTO team reviews code and architecture, infrastructure and deployment, security and access, payment and data flows, and how the developers work. The CTO reads the code themselves; there is no automated scan standing in for the review. Access is read-only, to the repository and the infrastructure, under NDA, and the company can revoke it the day the diagnostic ends.
The deliverable is a written verdict in plain English, ranked worst first. Each finding says what was found, why it matters to the business and what to do about it, with a verdict from "fix before launch" through "risky" and "can wait" to "keep". The "keep" findings matter as much as the rest: the architecture and the data model that are worth preserving are named, so a rebuild is never recommended by default. The report comes with a 30-day and a 90-day plan the company's own developers can follow, a debrief call, and, for a startup raising a round, a short note an investor or a regulator can read. The Fractional CTO page has a composite sample of the verdict page, drawn from published Valletta audits. For a real example of the same review on a live payments product, see the production-readiness audit of an EU fintech platform, where refunds that were not returned on failure were found alongside four more defects in access and migrations.
Buyer-side vs company-side due diligence
The checklist is the same on both sides of the table. What changes is who commissions it, when, and what they do with the result.
If you are the company, the practical version of company-side due diligence is short. Make sure the repositories, cloud accounts, domains and third-party services are owned by the company, not by a founder or a contractor. Rotate every secret and remove every former contributor's access. Get the dependency and licence list produced and read it. Write down the architecture on one page. Find the single points of knowledge and start documenting them. Then have someone outside the team read the code and tell you what an investor's reviewer will say. Most investors run a code review during due diligence; the only question is whether you hear the findings first.
How technical due diligence differs from a code audit
The two get confused because they overlap on the code. A code audit looks at one codebase and asks whether it is correct, secure and maintainable. Technical due diligence looks at the whole technology function, in the context of a transaction, and asks what it is worth and what it will cost. An audit is one of the inputs to due diligence; it is not a substitute for it.
For a product built with Cursor, Lovable, Bolt or similar tools, the lighter option is the right first step. The vibe coding cleanup audit, from $199, has a senior technical leader review what the AI tools actually shipped across eight weighted areas, including a Supabase row-level security review and prompt-injection testing for AI features. Our guide to reviewing a vibe-coded app before it goes live explains what that review looks for. When the product is the asset in a transaction, the full due diligence is the right tool.
Need technical due diligence on a deal, or before one?
Valletta's Fractional CTO team runs the review described above. Stas Gorshenin has run technology due diligence on seven retail and retail-tech deals for private equity funds, covering architecture, tech debt, team and security. For a startup raising a round, the diagnostic also gives you a short note an investor can read. Access is read-only under NDA, and the price is fixed on a 30-minute call.
FAQ
What is included in technical due diligence?
A review of the company's architecture, code quality and technical debt, security, infrastructure and DevOps, data handling, engineering team and process, and intellectual property including open source licences. The output is a report that ranks findings by business risk, estimates what they cost to fix, and gives the buyer a recommendation.
Who performs technical due diligence?
Usually an independent party commissioned by the investor or acquirer: a specialist consultancy, a fractional or interim CTO, or the fund's own technical partners. Independence matters because the reviewer should not profit from the outcome, for example by being hired to rebuild what they just criticised. Larger funds sometimes keep a technical adviser on retainer for every deal.
How long does technical due diligence take?
It depends on the size of the system, the scope the buyer wants and how quickly the company grants access. Valletta's technical diagnostic, which is the review described in this article, typically takes one to three weeks. Full M&A due diligence on a large platform runs longer, and a seed-stage review can be shorter.
What are the biggest red flags in technical due diligence?
Credentials still valid in production and committed to the repository. Endpoints that trust the client, so anyone can read or change data. One engineer holding most of the knowledge with nothing written down. Code written by contractors with no assignment of ownership. Copyleft licences in a commercial product with no plan for them. Backups that have never been restored. None of these are necessarily deal-breakers, but all of them change the price or the conditions.
How should a founder prepare for technical due diligence?
Run the same checklist on yourself first. Confirm the company owns every account, repository and domain. Rotate secrets and remove old access. Produce the dependency and licence list. Write the architecture on one page. Document the parts only one person understands. Then have an outside senior engineer read the code and tell you what the buyer's reviewer will find, so the fixes are done or at least listed before the data room opens.
Is a code audit the same as technical due diligence?
No. A code audit looks at one codebase for correctness, security and maintainability. Technical due diligence covers the whole technology function in the context of a deal, including team, data, infrastructure and intellectual property, and ends in a recommendation about price, conditions and the first months of ownership. A code audit is often one input to due diligence, and for an AI-built product it is the right place to start.