Technical Due Diligence Checklist for Software Projects

Evaluating a software project before a deal? See our Technical Due Diligence packages.

Read also: DevSecOps Implementation Checklist for Enterprise

Technical due diligence separates opinion from evidence. Whether you are acquiring a company, investing in a startup, evaluating a vendor, or auditing an internal project, this checklist provides a systematic framework for assessing the technical foundation. Each section includes specific items to evaluate and scoring guidance to quantify risk.

Area 1: Code Quality

Code quality is the most direct indicator of engineering discipline. Clean, well-structured code is easier to maintain, extend, and debug. Poor code quality signals accumulated shortcuts that will compound over time.

Automated analysis

• Run static analysis tools (SonarQube, ESLint, Pylint) — what is the overall quality score?
• Measure code coverage — what percentage of code is covered by automated tests? (Benchmark: 60-80% is good, below 40% is a red flag)
• Check cyclomatic complexity — high complexity indicates code that is difficult to understand and test
• Scan for code duplication — above 10% duplication suggests copy-paste development patterns
• Run dependency vulnerability scan — how many known CVEs exist in the dependency tree?

Manual code review

• Review naming conventions — are variables, functions, and classes named clearly and consistently?
• Assess separation of concerns — is business logic separated from infrastructure, presentation, and data access?
• Check error handling — are errors caught, logged, and handled gracefully, or do they propagate silently?
• Evaluate coding standards — is there a consistent style, or does each file look like it was written by a different person?
• Review recent commits — are commit messages meaningful? Do pull requests have reviews? Is the git history clean or chaotic?

Technical debt assessment

• Identify TODO/FIXME/HACK comments — count and categorize them
• Assess technological debt backlog — is there a documented list of known issues? Is it growing or shrinking?
• Evaluate code age distribution — what percentage of code has not been modified in 2+ years?
• Check for dead code — unused functions, unreachable branches, commented-out blocks

AI-generated code

• Establish provenance — which parts of the codebase were generated by AI assistants, and is that usage documented and governed by a policy?
• Check test coverage of generated modules — is AI-generated code covered by tests at least as well as hand-written code, or was it merged untested?
• Review generated code for licence leakage — could it reproduce snippets from open-source projects with incompatible licences?
• Scan generated code for leaked secrets and insecure patterns — hardcoded credentials, API keys, disabled validation (see why AI-generated code often contains vulnerabilities)

Scoring guide:

• Green (low risk): Coverage > 70%, no critical vulnerabilities, consistent style, manageable tech debt
• Yellow (moderate risk): Coverage 40-70%, some vulnerabilities, inconsistent style, growing tech debt
• Red (high risk): Coverage < 40%, critical vulnerabilities, no standards, overwhelming tech debt

Area 2: Architecture

Architecture determines how well the system can evolve, scale, and integrate. A sound architecture makes changes cheap. A poor architecture makes every change expensive and risky.

System design

• Document the high-level architecture — can the team explain it clearly? Does a diagram exist?
• Identify architectural pattern — monolith, microservices, modular monolith, event-driven? Is the choice appropriate for the system’s complexity?
• Assess coupling — how tightly are components connected? Can one component be changed without affecting others?
• Evaluate cohesion — does each component have a single, clear responsibility?
• Check for architectural drift — does the actual code match the documented architecture?

Data architecture

• Document the data model — is it normalized, documented, and consistent?
• Assess database choice — is the database appropriate for the data patterns (relational vs NoSQL vs time-series)?
• Check data migration strategy — is there a schema migration process? Are migrations version-controlled?
• Evaluate data integrity — are referential constraints enforced? Is there data validation at the application level?
• Assess backup and recovery — are backups automated, tested, and recoverable within defined RTO?

Integration architecture

• Map external integrations — APIs, third-party services, message queues, file transfers
• Assess integration resilience — what happens when an external service is slow or unavailable? (Circuit breakers, retries, fallbacks)
• Check API versioning — how are breaking changes managed for consumers?
• Evaluate message handling — are messages processed exactly-once or at-least-once? Is idempotency implemented?

Scoring guide:

• Green: Clear architecture, appropriate patterns, low coupling, documented data model
• Yellow: Partial documentation, some tight coupling, data model inconsistencies
• Red: No architecture documentation, monolith with tight coupling, undocumented data model

Area 3: Security

Security assessment identifies vulnerabilities that could lead to data breaches, compliance violations, or operational disruption.

Application security

• Run SAST scan — how many critical and high vulnerabilities exist?
• Run DAST scan — are there exploitable vulnerabilities in the running application?
• Check OWASP Top 10 coverage — injection, broken authentication, sensitive data exposure, XXE, broken access control
• Assess authentication implementation — password hashing algorithm, session management, MFA support
• Review authorization model — is access control role-based, attribute-based? Are permissions enforced consistently?
• Audit open-source licence obligations — is there copyleft code (GPL, AGPL) in distributed or SaaS-delivered software, and are licence obligations tracked in a software bill of materials?

Infrastructure security

• Review network architecture — are production systems in private subnets? Is ingress/egress controlled?
• Check data encryption — encryption at rest and in transit? What algorithms and key management?
• Assess secrets management — are credentials stored in code, environment variables, or a secrets manager?
• Review access controls — who has production access? Is access logged? Is MFA enforced?
• Check for security monitoring — intrusion detection, log analysis, alerting on suspicious activity

Compliance

• Identify applicable regulations (GDPR, SOC 2, HIPAA, PCI-DSS)
• Assess data privacy practices — PII handling, consent management, data retention policies
• Check audit trail — are critical actions logged with user identity, timestamp, and action detail?
• Review incident response plan — does it exist? Has it been tested?

Scoring guide:

• Green: No critical vulnerabilities, strong authentication, encryption everywhere, compliance-ready
• Yellow: Some vulnerabilities (no critical), partial encryption, compliance gaps
• Red: Critical vulnerabilities, weak authentication, plaintext secrets, no compliance framework

Area 4: Scalability and Performance

Scalability determines whether the system can handle growth without proportional cost increases or architectural rewrites.

Current performance

• Review performance metrics — response times (p50, p95, p99), throughput, error rates
• Check resource utilization — CPU, memory, disk, network at current load
• Identify bottlenecks — database queries, external API calls, compute-intensive operations
• Assess caching strategy — what is cached, where, and how is cache invalidation handled?

Scalability architecture

• Assess horizontal scalability — can the application scale by adding instances, or does it require vertical scaling?
• Check database scalability — read replicas, connection pooling, query optimization, sharding readiness
• Evaluate statelessness — can any instance handle any request, or is there session affinity?
• Review auto-scaling configuration — does the system scale automatically based on load?

Load and stress testing

• Has load testing been performed? What were the results?
• What is the maximum tested throughput? How does it compare to projected peak load?
• How does the system degrade under overload — graceful degradation or cascading failure?
• What is the recovery time after an overload event?

Scoring guide:

• Green: Horizontally scalable, load-tested, auto-scaling configured, 3x headroom above current peak
• Yellow: Vertically scalable only, limited load testing, manual scaling, 1.5x headroom
• Red: Cannot scale without rearchitecting, no load testing, at capacity

Area 5: Team and Process

Technology is only as good as the team building and maintaining it. Team assessment reveals whether the organization can sustain and evolve the system.

Team composition

• Map the team — roles, experience levels, tenure, areas of responsibility
• Identify key person dependencies — is critical knowledge concentrated in one or two people?
• Calculate the bus factor for critical modules — how many people would have to leave before nobody understands a given part of the system?
• Assess team stability — turnover rate over the past 12 months
• Evaluate hiring pipeline — how long does it take to fill open positions?

Development process

• Assess CI/CD maturity — automated build, test, and deployment pipeline
• Review branching strategy — is there a consistent workflow (GitFlow, trunk-based)?
• Check code review practices — are all changes reviewed before merge? What is the review quality?
• Evaluate release process — how often are releases deployed? What is the lead time from commit to production?

Knowledge management

• Assess project documentation — architecture docs, API docs, onboarding guide, runbooks
• Check code documentation — are complex functions documented? Is there an API reference?
• Evaluate onboarding process — how long does it take a new developer to make their first meaningful contribution?
• Review knowledge sharing practices — tech talks, documentation culture, pair programming

Scoring guide:

• Green: Full team, no single points of failure, mature CI/CD, comprehensive documentation
• Yellow: Some key person risk, basic CI/CD, partial documentation
• Red: High key person risk, manual processes, minimal documentation

Scoring Summary Template

Area	Weight	Score (1-5)	Weighted score	Key findings
Code quality	20%	_	_
Architecture	25%	_	_
Security	20%	_	_
Scalability	15%	_	_
Team & process	20%	_	_
Total	100%		_ / 5.0

Interpretation:

• 4.0-5.0: Low risk — system is well-built and maintainable
• 3.0-3.9: Moderate risk — specific areas need investment but no blockers
• 2.0-2.9: High risk — significant technical debt that will require substantial budget to address
• Below 2.0: Critical risk — fundamental issues that may require rearchitecting or rebuilding

When to Commission an External Audit

You can run parts of this checklist yourself, but an independent assessment pays off in a few situations:

• Before an acquisition or investment — when the decision depends on the findings, the assessment must be objective and the assessors must have no stake in the outcome.
• When your team would be assessing its own code — internal reviews rarely see their own blind spots, and their conclusions carry less weight with investors and boards.
• Before taking over a system from a vendor — you need to know the real state of the code, security and documentation before you sign off on the handover.
• When there is no in-house expertise in architecture, security or DevOps to run the checks with confidence.

Our Technical Due Diligence package covers the full code audit plus team and process, scalability, open-source licences and investor risks. It takes 2–3 weeks and starts from €8,500. If you only need the code-level view — quality, security and technical debt — the Code Health Audit takes 1–2 weeks and starts from €4,500.

How ARDURA Consulting Supports Technical Due Diligence

Technical due diligence requires experienced engineers who can assess code, architecture, and team practices quickly and objectively — skills that are difficult to find for short-term engagements.

• 500+ senior specialists across software architecture, security engineering, DevOps, and quality assurance — available within 2 weeks
• Rates about 35-55% below the average German IT freelance rate, with engagement flexibility from one-off assessments to ongoing technical advisory
• 99% specialist retention — engineers who provide honest, actionable assessments rather than generic findings
• 211+ completed projects — assessors who have seen what good and bad look like across dozens of technology stacks and industries

Whether you need a fixed-scope assessment on an M&A timeline or ongoing technical advisory for portfolio companies, ARDURA Consulting provides the engineering depth that turns due diligence findings into informed decisions.