A technical due diligence checklist should help you answer one question: can this company's technology support the business step you are about to take? That step might be an acquisition, an investment, a platform migration or a long contract with a software vendor. The checklist below covers eight areas, the evidence to request for each, the red flags worth logging and a way to write findings so a board or deal team can act on them.
TL;DR
- Technical due diligence tests whether software, infrastructure, people and legal rights can carry the plan you are paying for, not whether the code is elegant.
- Review eight areas: architecture, code and delivery, technical debt, security and compliance, data, intellectual property, team, and vendor or continuity risk.
- Ask for evidence (diagrams, test reports, access lists, license inventories), not for assurances.
- Rate each finding by severity and business impact, and attach a remediation estimate in time and cost.
- Start before you are committed. Findings arrive in time to change price, terms or plan only if the review runs early.
Table of Contents
- What technical due diligence is and when to run it
- How to run the review in five steps
- The technical due diligence checklist
- Software vendor due diligence: a shorter list
- Documents and access to request
- Red flags to log
- How to document findings
- Prepare your own product for review
- How Requestum can help
- FAQ
- Sources
What technical due diligence is and when to run it
Technical due diligence (TDD) is an independent look at a company's product and the systems behind it: architecture, code, infrastructure, security posture, tooling, roadmap and engineering team. In the US it usually appears in three situations:
- Investment. A seed or growth investor wants to know whether the product can scale and whether the team can build the roadmap it is pitching.
- M&A. A buyer needs to know what it is acquiring, what will break on Day 1, and what it will cost to integrate or fix.
- Vendor or platform selection. A company is about to build a core process on someone else's software and needs to know that vendor will still be reliable in three years.
The common thread is timing. A review that starts after terms are signed produces a report nobody can use. Run it while price, warranties, escrow and integration plans can still move. For a company preparing to be reviewed, the same logic applies: a self-assessment a month or two before a raise lets you fix the cheap problems first.
If you are weighing how diligence fits a financing or deal decision, AI agents for dealmaking are one way analysts are speeding up the document-heavy parts of a transaction. They support the review. They do not replace an engineer reading the architecture.
How to run the review in five steps
A checklist is only as good as the process around it. A workable sequence:
- Define the decision. Write down what the review must answer: "Can this platform handle three times the current load?" is a better scope than "assess the technology."
- Send a document request list. Ask for diagrams, repository access (read-only), cloud account summaries, security reports, contracts and the roadmap before any interviews.
- Interview the people. Talk to the CTO, a senior engineer and whoever owns security or operations. Compare their answers with the documents.
- Verify a sample. Pick the riskiest components and check them directly: run a dependency scan, read the deployment pipeline, review who has production access.
- Report and rank. Group findings by category, give each a severity and remediation estimate, and finish with a clear recommendation.
Sign an NDA before any code or customer data changes hands. Our guide to NDA redlines before a scoping call lists the clauses that matter when a third party will see your source code.
The technical due diligence checklist
Use the sections below as a working list. For each item, note what you asked for, what you received and what you could verify yourself.
1. Architecture and scalability
The goal is to find out whether the system you are looking at can support the growth plan, not just today's traffic.
- Current architecture diagrams: components, data flows, third-party services
- Monolith or services, and whether that choice fits the roadmap
- Known bottlenecks, load-test results and how load has trended over the past year
- Single points of failure: one database, one server, one engineer who understands one module
- Roadmap dependencies: features that need an architectural change first
- Deployment topology and disaster recovery plan, with the date it was last tested
If the diagrams do not exist or nobody can agree on what they show, log that as a finding on its own. Our article on web application architecture checks walks through patterns and deployment decisions you can use as a reference when judging what you are shown.
2. Code quality and delivery practices
You do not need to read every line. You need to know whether the team can change the code safely.
- Repository structure, naming, and consistency across modules
- Automated test coverage and whether tests run on every change
- CI/CD pipeline: how code reaches production, how long it takes, how often it fails
- Code review habits and branching strategy
- Dependency inventory and how out-of-date the main dependencies are
- Documentation: README files, runbooks, API docs, onboarding notes
- Release frequency over the last six to twelve months
Test quality matters as much as quantity. A large suite that nobody trusts is a signal. If the product has weak test coverage, an independent software testing and QA pass is a sensible part of the remediation plan.
3. Technical debt
Every real product has it. The question is how much, where, and what it will cost to carry or repay.
- A list of known shortcuts, legacy modules and unsupported frameworks
- Which debt blocks roadmap items and which merely slows the team
- Whether the team has a habit of paying it down (a dedicated share of each sprint, a backlog with owners)
- Estimated remediation effort, in weeks and cost
Debt is not automatically a deal-breaker. It becomes one when it blocks scaling, threatens security or makes the investment case more expensive than it looks. Our piece on technical debt reduction habits covers how teams keep it manageable, including in codebases with a lot of AI-generated code.
4. Security and compliance
Validate claims against evidence.
- Written security policies and proof they are followed
- Latest penetration-test report, with remediation status for each finding
- Access controls: who can reach production, how access is granted and removed, whether multi-factor authentication is enforced
- Encryption in transit and at rest, and key management
- Incident history: breaches, near misses, how they were handled
- Unresolved critical vulnerabilities in the code and dependencies
- Compliance reports such as SOC 2 or ISO 27001, where the customer base demands them
Read the scope of any SOC 2 report, not just its existence. A clean report covers the systems and controls its scope names, and it is not a review of the product's code. Treat it as one input next to your own technical checks. The web app security checklist gives eight testable controls with owners and evidence, which maps well onto a document request.
Also check development practices against a recognized baseline. The NIST Secure Software Development Framework describes practices for building software securely and gives you vocabulary for questions about how the target team builds and releases code.
5. Data and privacy
- Data inventory: what personal and sensitive data is collected, where it lives, who can see it
- Data residency and any cross-border transfers
- Backup, retention and deletion practices
- Compliance with privacy laws that apply to the customer base, such as CCPA and its amendments in California, or GDPR if the product serves EU users
- Third-party processors and the agreements with them
For SaaS targets with European users, the GDPR plan for SaaS founders shows what a mature program looks like at each stage.
6. Intellectual property and open source
This is where deals quietly fail.
- Signed IP assignment agreements from every employee and contractor who wrote code
- Ownership of anything built by an outside agency or freelancer
- An inventory of open-source components and their licenses, with attention to licenses that impose obligations on distributed or hosted code
- A software bill of materials (SBOM), which lists the components inside a product. CISA publishes guidance on SBOMs that explains what they contain and why buyers ask for them
- Third-party software and API terms that could restrict transfer or change of control
Missing assignments and unclear open-source licensing are among the most common red flags, and they are cheap to fix before closing and expensive afterward.
7. Team and organization
- Org chart, roles and tenure
- Key-person risk: who holds critical knowledge that is not written down
- Hiring plan against the roadmap, and how long open roles stay open
- Mix of employees and contractors, and where they are located
- Engineering culture: how decisions get made, how incidents are reviewed
- Retention risk after a deal: who is likely to leave, and what keeps them
A strong product with a team that is one resignation away from stalling is a different asset than the same product with shared knowledge and good documentation.
8. Infrastructure, cost and Day-1 continuity
- Cloud accounts, ownership and who holds the root credentials
- Monthly cloud spend by service, and how it scales with usage
- Monitoring, alerting and on-call practice
- Uptime history and the causes of past outages
- What must keep working on Day 1 after a transaction: domains, certificates, licenses, vendor contracts, support access
Software vendor due diligence: a shorter list
When you are buying software instead of a company, the same discipline applies in a lighter form. Focus on the questions that decide whether you can depend on the vendor:
| Area | What to ask for | Why it matters |
|---|---|---|
| Reliability | Uptime history, status page archive, incident write-ups | Shows how the product behaves under stress |
| Product fit | Roadmap, a demo against your real workflow | Features you need today and next year |
| Integrations | API documentation, rate limits, webhook support | Determines what you can connect without custom work |
| Security | Pen-test summary, SOC 2 or ISO 27001 scope, SBOM | Your exposure grows with theirs |
| Support | Response-time commitments, escalation path | What happens at 2 a.m. on a failure |
| Continuity | Escrow options, data export formats, exit terms | Whether you can leave without losing your data |
Our guide to software vendor selection covers six checks from SBOMs to support in more depth. If your vendor is a development agency building something custom, also confirm who owns the code and who can maintain it after handover.
Documents and access to request
Send one consolidated list at the start. A typical request covers:
- Architecture diagrams and system inventory
- Read-only repository access, or a supervised code walkthrough
- CI/CD configuration and release history
- Latest pen-test and vulnerability scan results
- Security policies, incident log and compliance reports
- Cloud billing summary and infrastructure account structure
- Employee and contractor agreements, including IP assignments
- Open-source license inventory or SBOM
- Product roadmap and engineering backlog
- Key vendor and customer contracts that depend on technical commitments
A virtual data room keeps this organized and logs who viewed what. Agree on the access level up front: reviewers rarely need write access to anything.
Red flags to log
Some findings deserve attention wherever they appear:
- Undocumented architecture or no one who can explain it
- Single points of failure in infrastructure or in people
- A breach history, or critical vulnerabilities that have sat unresolved
- Missing IP assignments, or code of unclear origin
- Open-source licensing conflicts
- No automated tests, or a release process that depends on one person
- Cloud spend that grows faster than revenue
- Answers in interviews that contradict the documents
One red flag rarely decides a deal. A pattern of them says something about how the company is run.
How to document findings
A report that sits unread in a data room has failed. Structure every finding the same way so readers can scan it:
| Field | Content |
|---|---|
| Category | Architecture, security, IP, team and so on |
| Description | What you found, in plain language |
| Evidence | Document, screenshot, command output, interview reference |
| Business impact | What it means for the plan, the price or the timeline |
| Severity | Critical, High, Medium or Low |
| Remediation | The fix, with estimated time and cost |
End the report with a clear recommendation: proceed, proceed with conditions, renegotiate or walk away. Rank findings by their effect on the investment case, so the board sees the three that matter before the thirty that do not.
Our perspective
We sit on both sides of this table. Companies hire us to build products that will one day be examined by an investor or a buyer, and others bring us in to repair what a review turned up. The pattern is consistent: the cheapest diligence is the kind you design for from the first sprint.
That means architecture decisions recorded when they are made, tests that run on every change, access that is granted deliberately and IP agreements signed before the first commit. A discovery phase and business analysis at the start of a project give you most of the documentation a reviewer will later ask for.
If you are on the buying side, our advice is to ask for evidence, rank what you find by business impact and treat technical debt as a cost to price in, not a verdict. A product with honest debt and a team that knows where it is can be a better asset than a clean-looking one nobody can explain.
Dmitry
Prepare your own product for review
If you are the one being examined, you can do most of the work in advance. Build the same document pack a buyer would request, run a dependency and vulnerability scan, close open IP gaps and write down who knows what. Then fix the items that would rank Critical or High before outside eyes see them. Treat the exercise as a normal part of engineering hygiene and not as a deal-week scramble.
How Requestum can help
We build web and mobile products, AI solutions and custom platforms, and we run business analysis, UI/UX design and QA as part of delivery. If your review turns up gaps in architecture, testing or security, we can scope the remediation work with you, from a discovery phase that sizes the problem to a dedicated team that carries out the fixes.
For startups preparing for a raise, our software development for startups service helps teams build with investor review in mind. To talk through a specific product, start at requestum.com.
FAQ
How long does technical due diligence take?
It depends on the size of the system and the quality of the documentation. A focused review of a small product can take days, while a full review of a complex platform with several codebases takes longer. A prepared target with a ready document pack shortens the process noticeably.
Who should conduct technical due diligence?
The best reviewer is someone independent of both the seller and the team that built the product, with senior engineering and architecture experience. Buyers often use an outside specialist or a fractional CTO. Internal reviewers are fine for vendor assessments when they understand the systems involved.
Is technical debt a reason to stop a deal?
Not by itself. What matters is whether it blocks the roadmap, creates security exposure or makes the product costly to run. Estimate the cost to fix it, compare that with the price and negotiate accordingly.
What is the difference between IT due diligence and software due diligence?
IT due diligence is broader: it includes networks, endpoints, internal systems, licenses and IT operations. Software due diligence concentrates on the product itself: code, architecture, delivery practices and IP. Many reviews of technology companies cover both.