What are you actually buying?

The questions a technical due diligence asks, in the order it asks them. You get a risk score, an investment grade, and the things that would stop the deal.

  • 35 questions
  • 7 areas
  • about 11 minutes
  • stays in your browser

What's included

This comprehensive 96-item checklist covers every aspect of technical due diligence:

1. Architecture and Technical Design (15 items)

System architecture documentation, scalability assessment, and technology stack evaluation.

2. Code Quality and Technical Debt (15 items)

Code standards, technical debt tracking, and documentation quality review.

3. Testing and Quality Assurance (10 items)

Test coverage analysis and quality process assessment.

4. Security (16 items)

Application security, security practices, and compliance verification.

5. Infrastructure and Operations (15 items)

Hosting, deployment, monitoring, and disaster recovery evaluation.

6. Team and Processes (15 items)

Team capability, development processes, and CI/CD assessment.

7. Data and Integrations (10 items)

Data management and third-party integration review.

Plus: Summary scorecard, risk assessment matrix, findings template, and recommendations framework.

This is the same checklist used by professional investors and acquirers. Download now to conduct your own rigorous assessment.

Who it's for

This checklist is designed for anyone making high-stakes decisions involving technology assets.

  • Investors and VCs - Conducting due diligence before Series A and beyond? Use this checklist to validate technology claims, identify hidden technical debt, and understand the true state of the engineering organisation before committing capital.

  • Founders preparing for funding or exit - Know what investors will scrutinise. Run this assessment internally to identify and address weaknesses before they become negotiation points or deal-breakers.

  • Non-technical board members - Gain meaningful visibility into technology risks without needing to understand code. The scoring framework translates technical findings into business risk language.

  • CTOs and engineering leaders - Benchmark your technology organisation against professional standards. Identify blind spots and build a prioritised improvement roadmap.

  • M&A teams and corporate development - Whether acquiring technology companies or evaluating strategic partnerships, this checklist ensures consistent, thorough evaluation across all technology dimensions.

If technology is central to the value you are evaluating, protecting, or building - this checklist is for you.

The assessment

1. Architecture & Technical Design
How well documented is your system architecture?

Consider: architecture diagrams, component responsibilities, data flows, integration points, and decision records.

Can your system handle 10x current load?

Consider: horizontal scaling capability, database performance at scale, caching strategies, and load testing results.

How current is your technology stack?

Consider: framework versions, language versions, dependencies, and end-of-life software.

How clearly defined are system components and their responsibilities?

Consider: separation of concerns, module boundaries, API contracts between components.

How manageable are your external integrations?

Consider: number of third-party services, API versioning, fallback handling, and vendor relationships.

2. Code Quality & Technical Debt
Are coding standards documented and enforced?

Consider: style guides, linting, static analysis, code review requirements.

How is technical debt managed?

Consider: debt tracking, prioritisation, allocated capacity for debt reduction.

How are dependencies managed?

Consider: package managers, version pinning, vulnerability scanning, update frequency.

How well is the codebase documented?

Consider: README files, API docs, inline comments, runbooks, onboarding guides.

Is refactoring part of regular development?

Consider: frequency of refactoring, "boy scout rule" adoption, legacy code improvement.

3. Testing & Quality Assurance
What level of automated test coverage exists?

Consider: unit tests, integration tests, end-to-end tests, coverage metrics.

How automated is your test execution?

Consider: CI/CD integration, pre-commit hooks, automated regression on deploy.

How mature is your QA process?

Consider: defined QA workflow, acceptance criteria, sign-off process.

How effectively are bugs managed?

Consider: bug tracking, prioritisation, response times for critical issues.

Is performance testing conducted?

Consider: load testing, stress testing, performance benchmarks, response time monitoring.

4. Security
How is authentication and authorisation implemented?

Consider: auth protocols (OAuth2, OIDC), session management, permission models.

How is sensitive data protected?

Consider: encryption at rest, encryption in transit, access controls, key management.

How are security vulnerabilities managed?

Consider: vulnerability scanning, penetration testing, patch management, security updates.

What is your compliance status?

Consider: GDPR, data retention, privacy policies, industry-specific regulations.

Do you have a security incident response process?

Consider: incident response plan, contact procedures, communication protocols, post-incident reviews.

5. Infrastructure & Operations
How automated is your deployment process?

Consider: CI/CD pipelines, infrastructure as code, deployment frequency, manual steps.

What monitoring and observability is in place?

Consider: application logging, metrics, tracing, alerting, uptime monitoring.

What disaster recovery capability exists?

Consider: backup automation, RTO/RPO definitions, DR plan, recovery testing.

How are environments managed?

Consider: number of environments, environment parity, data isolation, promotion process.

Can you roll back a failed deployment?

Consider: rollback automation, rollback testing, time to rollback, data migration handling.

6. Team & Processes
Is the team appropriately skilled for the technology?

Consider: technology expertise, domain knowledge, experience levels, skill gaps.

What is your "bus factor"? (How many people could leave before critical knowledge is lost?)

Consider: knowledge distribution, documentation, cross-training, key person dependencies.

How effective is your development methodology?

Consider: agile adoption, sprint consistency, velocity predictability, retrospectives.

How mature is your CI/CD practice?

Consider: pipeline automation, build times, deployment frequency, feature flags.

How effective is stakeholder communication?

Consider: regular updates, requirement clarity, feedback loops, documentation.

7. Data & Integrations
How well documented is your data model?

Consider: entity relationship diagrams, data dictionary, schema documentation, data lineage.

How are database migrations handled?

Consider: version control, rollback capability, migration testing, data integrity.

How dependent are you on third-party services?

Consider: critical dependencies, fallback handling, vendor concentration, cost exposure.

What is your vendor lock-in risk?

Consider: proprietary technologies, data portability, contract terms, migration complexity.

How are APIs versioned and maintained?

Consider: version strategy, backward compatibility, deprecation policy, documentation.

Questions about this assessment

What is technical due diligence?

Technical due diligence is a comprehensive assessment of a company's technology assets, architecture, team capability, and processes. It identifies risks, hidden liabilities, and opportunities before M&A transactions, investments, or significant partnerships. The goal is to verify that technology claims match reality and to understand the true state of the technology organisation.

When should I conduct technical due diligence?

You should conduct technical due diligence before any significant financial commitment involving technology: acquisitions, major investments, partnership agreements, or when joining a company at board or executive level. Early-stage investors may conduct lighter assessments, while later-stage or acquisition scenarios typically require comprehensive reviews covering all 96 items.

How long does a technical due diligence assessment take?

A thorough technical due diligence typically takes 3-5 days of active assessment time, depending on system complexity and access to documentation, code, and team members. The elapsed time is usually 2-4 weeks to allow for scheduling interviews, reviewing materials, and producing the final report with recommendations.

Can I conduct due diligence myself or do I need an external consultant?

Internal teams can use this checklist for self-assessment or preliminary reviews. However, for high-stakes transactions, external consultants bring objectivity, cross-industry benchmarking, and established frameworks. Independent assessment is often expected by investors and boards, and external consultants can identify issues that internal teams may overlook or downplay.

What happens if the assessment reveals problems?

Discovering issues during due diligence is valuable - it allows you to renegotiate terms, request remediation before completion, or make an informed decision to proceed, delay, or walk away. The checklist includes a findings template to document red flags (immediate concerns), amber flags (areas requiring attention), and positive findings to give a balanced view.