Tech Due Diligence in 2026: What VCs and Acquirers Should Actually Look For

Most technical due diligence reports VCs receive are 40 pages of nothing. A summary of the target’s pitch deck, screenshots of their AWS console, and a paragraph about “scalable microservices architecture” written by someone who didn’t open the codebase. The associate who commissioned it skims it, the partner signs the term sheet, and 18 months later the portfolio company is rewriting everything because the original platform is held together with cron jobs and the only engineer who understands the payment flow just quit.

Real tech DD is engineering work. Not consulting work. It requires people who have actually shipped production systems sitting in the codebase for a week and asking uncomfortable questions. Here’s how we run it.

Why most VC due diligence is shallow

The Big Four DD practices generate reports priced at $80-150K. Most of that price buys process. Three associates with general consulting backgrounds will interview the CTO, run a Snyk scan, count lines of code, generate charts. The deliverable looks professional. None of the findings will surprise the founder.

What you actually need: an engineer with 10+ years of experience who reads the code, talks to the team without the CTO in the room, runs the deploy pipeline themselves, and tells you in plain English where the bodies are buried. That work costs us $7-25K depending on company size and we deliver it in 1-3 weeks.

The investors who get burned aren’t the ones who skipped DD. They’re the ones who paid $100K for a DD that confirmed what they wanted to hear.

The 5-area framework we use

We assess every target across five dimensions. Each gets a 1-5 score, an evidence list, and a remediation cost estimate in engineering-months.

1. Code quality

We pull the repo and read it. Yes, actually read it. We look at:

• Test coverage that means something. Not the line-coverage number from CI — the actual test suite. Are there integration tests around money flow? Around auth? Around the customer-facing API contract? A 70% line-coverage repo with no integration tests is worse than a 30% repo with solid contract tests.
• PR cadence and review depth. We pull the last 90 days of PRs. Are reviews substantive or rubber-stamped? Are PRs squashed into “WIP” commits or do they tell a story? Is one person reviewing 80% of merges (key-person risk)?
• Code archeology. git blame on the 20 highest-traffic files. If 60% of the critical-path code was written by one person who left 8 months ago, that’s a finding the founder won’t volunteer.
• TODO and FIXME density. A repo with 400 unresolved FIXMEs has a different operating culture than one with 12.

2. Architecture and scalability

The pitch deck says “we can scale to 10M users.” We test the claim. Not by trusting AWS slides — by reading the actual hot paths.

• Is the auth system a monolithic shared-secret model or does it support multi-tenancy cleanly?
• Where are the N+1 queries hiding? We run EXPLAIN ANALYZE on the top 20 query patterns.
• What’s the actual database growth rate vs the schema design? A B2B SaaS storing all customer events in a single Postgres table without partitioning is a 9-month time bomb.
• How does the system fail under load? We look at the last 6 months of incidents and post-mortems (if they exist). No post-mortems is itself a finding.

3. Security posture

Most early-stage targets have no security program. That’s expected. What we assess is whether the gaps are the normal startup gaps or the gaps that will torpedo enterprise sales.

We run:

• A SAST scan (Semgrep, GitHub Advanced Security) for known vulnerability classes.
• A DAST pass against staging (OWASP ZAP, Burp Suite) for the public surface.
• A threat model of the auth and authorization layer — not for compliance, for actual attacker paths.
• A review of secrets management. If we find AWS keys in the repo, that’s not a finding, that’s a phone call to the partner the same day.
• IAM and cloud config review. Public S3 buckets, overly permissive roles, root account usage, no MFA on the GitHub org. The boring stuff that gets companies breached.

We also ask: can this company pass a SOC 2 Type I in 90 days, or will it take 9 months? That answers whether enterprise revenue is gated by 1 quarter or 1 year.

4. DevOps and operational maturity

• Can a new engineer deploy on day one? We try to follow the README. If the answer is “the deploy script only works on Andre’s laptop,” we flag it.
• Is infrastructure in Terraform / Pulumi / CDK, or is it ClickOps? A 4-year-old company with no IaC is a 6-month remediation.
• What does the on-call rotation look like? If there’s no on-call rotation and the CTO carries the pager alone, the company has a hidden personnel risk.
• Backup and disaster recovery. Most targets have never tested a restore. We ask them to.

5. Team and culture

This is the dimension most DD reports skip, and it’s the one that decides whether the integration or post-investment plan survives contact with reality.

We interview engineers without the CTO present. Questions we ask:

• “Walk me through how a feature gets from idea to production.”
• “What’s the worst piece of tech debt in the codebase, and why hasn’t it been fixed?”
• “Tell me about the last time you disagreed with a technical decision. How did it go?”
• “Who would you not want to lose?”

The CTO’s answers and the engineers’ answers should rhyme. When they don’t, you’ve found something. The most common version of “they don’t rhyme”: the CTO believes the team is empowered; the engineers describe a culture where pushing back gets shut down.

Red flags that should kill or reprice the deal

Some findings are interesting. Some are dealbreakers. The ones that make us pick up the phone to the partner mid-engagement:

• No tests at all. Not low coverage — zero meaningful tests on a 4-year-old codebase. This isn’t laziness; it’s a culture that ships and prays.
• A single deployable monolith with no module boundaries and a team of 12 engineers all touching it. Velocity has already collapsed; the founders haven’t admitted it yet.
• Auth bolted on after the fact. Permissions checked in the UI but not the API. We can usually demonstrate IDOR (insecure direct object reference) within an afternoon.
• No CI or a CI that’s been red for weeks. It tells you everything about the operating cadence.
• Single-person dependency on a critical system. “Only Ravi understands the billing service.” Ravi is now a $5M risk on your cap table.
• Customer data with no encryption at rest, in an unencrypted backup, in a public S3 bucket. We’ve seen this. More than once.

Less catastrophic but repricing-worthy: heavy reliance on a single cloud vendor’s proprietary service with no abstraction (lock-in), critical third-party APIs with no fallback (DocuSign, Stripe Connect, Twilio dependencies that aren’t isolated), customer-specific code branches in main (the company is secretly a consulting shop).

What good DD output looks like

Our deliverable has three layers, written for three audiences.

Layer 1: Executive summary (2-3 pages). For the investment committee. Plain English. Top 5 risks, top 5 strengths, recommendation (proceed / proceed with conditions / pass), and a one-paragraph remediation budget.

Layer 2: Technical findings (15-25 pages). For the CTO who’ll be working with this team post-close. Each finding has: what we observed, evidence (commits, file paths, screenshots), severity, and a remediation estimate in engineering-weeks.

Layer 3: Raw artifacts. Scan outputs, threat model diagrams, query plans, screenshots of console findings. Auditable. The acquirer’s tech team can reproduce our work.

The remediation budget is the most useful part for repricing. “The platform needs $400K and 4 months of engineering work to get to acquirer-grade reliability” is a number you can subtract from the valuation. “Their codebase has some technical debt” is not.

Tools we actually use

We’re not religious about tooling but here’s what’s in the standard kit:

• Code analysis: Semgrep, GitHub Advanced Security, SonarQube for some engagements, manual review for everything that matters.
• Dependency / SCA: Snyk, Dependabot, OSV-Scanner.
• DAST: Burp Suite Pro, OWASP ZAP for the open-source pass.
• Cloud config: AWS Security Hub, ScoutSuite, Prowler. For GCP, Forseti or Cloud Security Command Center.
• Infrastructure review: Terraform plan diffs, drift detection via terraform plan against actual state.
• Codebase metrics: Custom scripts that pull contributor distribution, file-level churn, comment density. Nothing magic; just enough to flag concentration risk.

The tools aren’t the differentiator. The judgment about which findings matter is.

Pricing and timing

• Standard tech DD for a Series A target (15-30 engineers, 1-3 products): from $7K, 1-3 weeks.
• Acquisition DD for a larger target or where post-close integration planning is needed: $15-25K, 2-4 weeks.
• Pre-investment lite review when you want a second opinion in 5 days: $3-5K, 5 business days.

We sign mutual NDA before the kickoff. We work under the acquirer or investor’s name (the target doesn’t see “Softronic” anywhere if you prefer). All findings are yours.

Bottom line

If you’re writing a check above $2M, paying 0.3-0.5% of the check size for independent engineering DD is the cheapest insurance you can buy. Most of the time you’ll confirm what you already believed and proceed with more conviction. Sometimes you’ll catch the thing that would have cost you the fund.

We can start a tech DD engagement next week. The first 30-minute call is free and includes a scoping conversation.