What VCs Actually Look for in a Tech DD

The real checklist

After 300+ technology due diligence engagements for VC and PE funds across Europe, the pattern is clear. Investors are not checking whether your code is beautiful. They are checking whether the technology can support the business plan they are about to fund.

Here is what actually gets evaluated, in order of how much it affects the investment decision.

1. Code quality and technical debt

This is the most requested assessment area. Not because investors care about coding style, but because technical debt is a proxy for future burn rate.

What gets checked:

• Test coverage: Not the percentage number, but whether critical paths are tested. 40% coverage on the right things beats 90% coverage on getters and setters.
• Dependency health: How many dependencies are unmaintained, end-of-life, or have known vulnerabilities? A single critical CVE in a core dependency can delay a release by weeks.
• Code complexity: Are there files or modules that only one person can modify? Cyclomatic complexity in critical business logic.
• Release frequency: How often does the team ship to production? Long release cycles correlate with fragile deployment processes.
• Known debt: Does the team track technical debt explicitly, or does it accumulate silently? A team that maintains a tech debt backlog and actively prioritizes it demonstrates maturity.

What creates negative findings:

• No automated tests for payment processing, authentication, or data handling paths.
• Dependencies more than two major versions behind.
• “Only Sarah knows how that module works” - heard in every third engagement.
• Last production deploy was six weeks ago.

2. Architecture scalability signals

Investors funding a growth round want to know whether the architecture can handle 10x the current load without a rewrite.

What gets checked:

• Data model: Is the database schema normalized appropriately? Are there obvious scaling bottlenecks (e.g., global locks, single-server state)?
• Service boundaries: If the application is a monolith, is it a well-structured monolith with clear module boundaries? If microservices, are the boundaries logical or were they drawn prematurely?
• Stateless design: Can the application scale horizontally? Is session state externalized?
• Caching strategy: Is caching intentional and documented, or ad-hoc and scattered?
• Data volume projections: What happens to query performance when the dataset grows 10x? Has anyone run load tests?

What creates negative findings:

• A monolith with 200+ database tables, no module boundaries, and no path to horizontal scaling.
• Premature microservices architecture for a team of five engineers. The operational overhead is eating the team alive.
• No load testing results. “We have not tested above current production load.”
• Single-point-of-failure databases without read replicas or failover.

3. Security posture basics

Investors are not hiring penetration testers during DD (they might later). They are checking whether basic security hygiene exists.

What gets checked:

• Authentication and authorization: Is auth centralized? Are there hardcoded credentials in the codebase? Is MFA enforced for internal tools?
• Data encryption: Is data encrypted in transit (TLS)? At rest? Are encryption keys properly managed?
• Secrets management: Are API keys, database passwords, and tokens stored in environment variables or a secrets manager, or are they committed to the repository?
• Access control: Who has production database access? Is it the entire engineering team, or is it restricted to operations?
• Vulnerability management: Is there a process for addressing security vulnerabilities? How long do critical CVEs sit unpatched?

What creates negative findings:

• Secrets committed to Git history. Even if they have been “removed,” they are in the history.
• Every engineer has production database write access.
• No HTTPS on internal services because “it is behind the VPN.”
• Last dependency security scan was never.

4. Team structure and bus factor risk

This is the area that founders most underestimate. Investors know that the team they are funding is the team that needs to execute.

What gets checked:

• Bus factor: How many people need to leave before a critical system becomes unmaintainable? For most startups, the honest answer is one or two.
• Documentation: Not comprehensive wiki pages, but whether a new engineer can onboard without shadowing someone for a month. README files, architecture decision records, and runbooks matter.
• Hiring pipeline: Is the team growing? Are there unfilled positions that are blocking progress?
• Knowledge distribution: Are code reviews happening? Does more than one person understand each system component?
• Team-to-codebase ratio: A four-person team maintaining six microservices, two mobile apps, and an admin panel is spread too thin. Investors notice.

What creates negative findings:

• A single founder wrote 80% of the codebase and is now the CEO with no time to code.
• No onboarding documentation. “We pair-program for the first two weeks.”
• Code review approval from one person for all changes.
• Three months of open positions in engineering with no hires.

5. Documentation maturity

Documentation is not about having a wiki. It is about whether organizational knowledge survives personnel changes.

What gets checked:

• Architecture decision records (ADRs): Are significant technical decisions documented with context and rationale?
• API documentation: Can a new team member or external integrator understand the API without reading source code?
• Runbooks: Does the operations team have documented procedures for common incidents?
• Deployment documentation: Can someone who did not build the deployment pipeline deploy the application?

What creates negative findings:

• No architecture documentation at all. “It is all in our heads.”
• API documentation that is six months behind the actual API.
• Deployment process that only the DevOps engineer understands.

6. Infrastructure cost efficiency

Cloud bills are a leading indicator of engineering discipline. Investors look at infrastructure spend relative to revenue and user base.

What gets checked:

• Cost per user or per transaction: Is infrastructure spend proportional to business metrics?
• Resource utilization: Are you running r5.4xlarge instances at 5% CPU utilization?
• Autoscaling: Does infrastructure scale with demand, or are you paying for peak capacity 24/7?
• Environment parity: Are staging and development environments significantly smaller than production, or are they full mirrors running around the clock?
• Vendor lock-in: How dependent is the architecture on proprietary services? What would a migration cost?

What creates negative findings:

• Monthly cloud bill growing faster than revenue.
• No cost monitoring or allocation. “We do not track which service costs what.”
• Running production-sized environments for development.
• A single cloud provider with deep lock-in and no exit plan.

How AuditFront structures this

AuditFront’s Tech DD framework translates these six areas into 40 specific, auditable controls - organized the same way an experienced auditor would structure a real engagement:

• Code Quality & Engineering Practices: 10 controls covering testing, dependencies, release process, and debt management.
• Architecture & Scalability: 9 controls covering data model, service design, scaling strategy, and performance.
• Security & Compliance Posture: 8 controls covering auth, encryption, access control, and vulnerability management.
• Team & Knowledge Management: 6 controls covering bus factor, documentation, onboarding, and knowledge distribution.
• Operations & Infrastructure: 7 controls covering deployment, monitoring, cost management, and incident response.

The self-assessment format lets founders run a Tech DD on themselves before investors bring their own auditors. Knowing your gaps in advance means you can fix them - or at least have honest answers ready.

Start a free Tech DD assessment to see where your technology stands against what investors actually evaluate.