Technical due diligence is an independent review of a company's software, infrastructure and engineering team before an investment or acquisition. It shows whether the product can scale, what it will cost to fix and which risks belong in the deal terms. A focused review takes one to two weeks.
Key takeaways
- Tech DD answers one question for the buyer or investor: what will this technology cost us after the deal?
- Review seven areas: architecture, code quality, security, infrastructure and cost, team and process, IP and licenses, and scalability.
- Red flags matter more than scores. One missing backup or a GPL dependency in a closed product can outweigh tidy code.
- Founders should run the same checklist on themselves a few months before fundraising.
- Expect a written report with ranked findings and remediation costs, not a pass or fail grade.
What technical due diligence covers
Technical due diligence covers everything that decides how expensive the product will be to run, change and grow after the deal. It is wider than a code review: the reviewers look at the people and processes behind the code, the cloud bill and the legal status of every component.
A typical review has three parts:
- Document and access review. Architecture diagrams, repository access, cloud console read access, incident history, the roadmap.
- Hands-on analysis. Reading the code, running static analysis and dependency scans, checking the cloud setup and reproducing a deploy.
- Interviews. One to two hours each with the CTO, a senior engineer and whoever runs operations, to test what the documents claim.
Investors use the findings to adjust valuation, add conditions to the term sheet or plan the first 100 days. Founders use the same review to fix problems before a buyer finds them. If you are earlier than that and still shaping the product, a discovery phase is the better first step.
Technical due diligence checklist by area
The checklist below groups what reviewers check into seven areas, with the red flags that should change the conversation. Use it as a working document: each row is a question the target company should be able to answer with evidence.
| Area | What we check | Red flags |
|---|---|---|
| Architecture | System diagram, main components, how data flows, single points of failure | No one can draw the system; one server runs everything; core logic lives in a vendor tool you cannot export |
| Code quality | Structure, test coverage on critical paths, static analysis results, code review practice | No tests on payments or permissions; large files nobody wants to touch; review happens only for some changes |
| Security | Access control, secrets handling, dependency vulnerabilities, OWASP Top 10 risks, past incidents | Secrets in the repository; admin panels open to the internet; no record of past incidents |
| Infrastructure and cost | Hosting setup, infrastructure as code, backups, monitoring, the monthly cloud bill per customer | Manual server setup; backups never restored; cloud cost growing faster than revenue |
| Team and process | Who knows which part of the system, release frequency, on-call, documentation | One engineer holds all the knowledge; releases are rare and stressful; no written runbooks |
| IP and licenses | Code ownership, contractor agreements, open source licenses, third-party terms | Contractors without IP assignment; GPL or AGPL code inside a closed product; unlicensed components |
| Scalability | Load profile, database growth, performance under 10x traffic, known bottlenecks | No load tests; database queries that slow down with every new customer; limits nobody has measured |
Architecture
Start with a diagram the team draws from memory, then compare it with what runs in the cloud account. Gaps between the two are findings in themselves. Look for single points of failure and for business logic locked inside tools that cannot be exported or replaced.
Code quality
Code quality is judged on the parts that carry risk, not on style. Payments, permissions and data exports need tests and reviewed changes. Static analysis gives a quick map of where problems cluster, but the reviewer still needs to read the code around the findings.
Security
Security review checks the risks in the OWASP Top 10:2025, starting with broken access control. Scan the full Git history for leaked secrets, list internet-facing admin tools and ask for the incident log. If the product was built quickly with AI tools, our list of vibe coding security risks covers the gaps those apps usually have.
Infrastructure and cost
Ask for three months of cloud bills and divide by active customers. A cost per customer that grows with scale is a design problem, not a pricing one. Confirm that backups exist and that someone has restored one recently.
Team and process
The fastest signal is how often the team ships and how often a release goes wrong. DORA's delivery metrics, such as change lead time, deployment frequency and change fail rate, give a shared vocabulary for this (DORA). Ask who could fix a production incident at night if the lead engineer were away.
IP and licenses
Check that every employee and contractor assigned their rights to the company. Then scan open source licenses. Black Duck's 2025 open source report found license conflicts in 56% of audited codebases, vulnerabilities in 86% and components more than four years out of date in 90% (Black Duck). Copyleft licenses such as the GPL can require you to publish source code when you distribute the software, and the AGPL extends that to software used over a network (GNU GPL FAQ, GNU AGPL).
Scalability
Ask what happens at ten times today's traffic and what evidence supports the answer. Without load tests, the honest answer is "we don't know", which is a finding but not always a deal breaker. Look at the slowest database queries and how they grow with data volume.
How long technical due diligence takes and what you get
A technical due diligence review takes one to two weeks for a single product, and two to four weeks when there are several products, a large codebase or deeper security testing. Most of the time goes into hands-on analysis; interviews take one or two days.
These are Join.To.IT estimates; the exact scope is fixed after a first call and access to the code.
| Scope | What it covers | Timeline | Cost |
|---|---|---|---|
| Code audit | One codebase: code quality, security and dependency scan, ranked findings | Up to 1 week | $300–$800 |
| Technical due diligence | One product across all seven areas, with team interviews | 1–2 weeks | $1,000–$2,500 |
| Extended due diligence | Several products or services, load and security testing | 2–4 weeks | $2,500–$6,000 |
The report should include:
- Executive summary. One page with the overall assessment and the three to five findings that matter for the deal.
- Findings by area. Each finding with evidence, a risk level and the business impact.
- Red flags. Anything that should change valuation, deal terms or timing.
- Remediation plan. What to fix, in what order, with time and cost ranges.
- Appendix. Architecture diagram, dependency and license list, metrics collected during the review.
How founders can prepare for technical due diligence
Founders should prepare for technical due diligence three to six months before a raise or sale, by running the checklist on their own product and fixing the cheap problems first. Issues you find and fix yourself are a footnote; the same issues found by the investor's reviewer become a negotiating point.
A practical order of work:
- Collect the documents. An up-to-date architecture diagram, a list of third-party services and what each one costs, the incident log for the last year and a short description of how a release reaches production.
- Clean up access and secrets. Remove former employees and contractors from repositories and cloud accounts, rotate keys that were ever shared in chat or committed to Git, and turn on two-factor sign-in for admin accounts.
- Check the paperwork. Make sure every contractor signed an IP assignment and run a license scan, so you know about copyleft code before someone else points it out.
- Prove recovery. Restore a recent backup to a separate environment and write down how long it took.
- Write down what only one person knows. A few pages of runbooks for deploys, incidents and key integrations reduce the "one engineer holds everything" finding.
None of this needs a rewrite. Most teams can do it in a few weeks alongside normal work.
Tech DD vs code audit vs security audit
The three reviews answer different questions. A code audit asks whether the code is maintainable, a security audit asks whether the product can be attacked, and technical due diligence asks whether the technology supports the business plan.
| Code audit | Security audit | Technical due diligence | |
|---|---|---|---|
| Main question | Can we keep building on this code? | Can someone break in or leak data? | What will this technology cost us after the deal? |
| Typical buyer | CTO, new tech lead, founder | CTO, compliance, enterprise customer | Investor, acquirer, board |
| Scope | Code, tests, dependencies | Application, infrastructure, access, often penetration testing | Code, security, infrastructure, team, process, IP, cost |
| Output | Findings and refactoring plan | Vulnerabilities by severity and fixes | Report for a deal decision, with red flags and remediation costs |
| Typical duration | Up to 1 week | 1–3 weeks | 1–4 weeks |
If the review shows the product needs serious work, the same team can take it on. That is the usual path in our software rescue projects.
How Join.To.IT can help
Join.To.IT runs technical due diligence and code audits for investors, acquirers and founders preparing to raise. We review the code, cloud setup, security, team process and licenses, interview the engineers and deliver a report with ranked findings, red flags and remediation costs. If you go ahead, our engineers can fix what the review found. See software rescue or, for an app built with AI tools, AI MVP to production.
In a recent audit of a US legal-compliance e-learning platform built on WordPress plugins, the review found course logic duplicated for every state, business rules that could not be verified outside plugin behavior and deploys with no tests. The findings made the decision clear: a rebuild with one admin for all states and automated deploys, rather than another round of plugin fixes.
FAQ
Who performs technical due diligence?
Technical due diligence is usually performed by an independent engineering firm or a small team of senior engineers hired by the investor or acquirer. Some funds have in-house technical partners who lead the review. The reviewers should have no stake in the deal and should include someone who has run production systems, not only written code.
How long does a tech DD take?
A tech DD for one product usually takes one to two weeks from receiving access to delivering the report. Larger companies with several products, complex infrastructure or a need for penetration testing take two to four weeks. The biggest delay is usually access: repositories, cloud accounts and interview slots should be ready on day one.
What are red flags in a codebase?
Common red flags are secrets stored in the repository, no tests on payments or permissions, one engineer who understands critical parts alone, backups that were never restored and copyleft-licensed code inside a closed product. Each one can be fixed, but each has a cost that belongs in the deal terms or the first-year plan.
How much does a code audit cost?
By Join.To.IT estimates, a code audit of one codebase costs $300–$800 and takes up to a week. Full technical due diligence for one product, including infrastructure, team interviews and licenses, costs $1,000–$2,500 over one to two weeks. Reviews of several products with load and security testing run $2,500–$6,000.
.png.png)
