Tech Due Diligence Red Flags
Twelve technical diligence red flags that consistently predict repricings, walked deals, and post-close write-downs in SaaS and AI acquisitions.
Written by Hutton Henry
Founder, Beyond M&A · Creator, Lens
Last reviewed 20 May 2026
How we researchExecutive summary
Twelve patterns we see repeatedly in failed or repriced deals. None is automatically disqualifying; together they signal a target that will cost materially more to operate than the projections assume.
- 01Single-engineer key-person risk on a production-critical system is the most predictive red flag of post-close repricing.
- 02Cloud-cost discrepancies between disclosure and invoices precede 70% of post-close margin surprises we've audited.
- 03A clean penetration test with one Critical finding is more dangerous than a busy report with everything Medium.
These are the twelve technical patterns we flag most often in buy-side diligence engagements. None is automatically disqualifying; together, they signal a target that will cost materially more to operate than the projections assume.
1. Key-person concentration on a production-critical system
The classic. One engineer, usually a co-founder, who owns a system that touches money or customer data. Mitigation costs are retention packages and 12-month parallel rebuilds.
2. Cloud-cost disclosure that doesn't match the invoices
Pull the actual cloud bills, not the management accounts' allocation. Discrepancies over 15% almost always trace to customer concentration the seller doesn't want disclosed.
3. A clean pen test with exactly one Critical
A real engineering team finds Medium and Low issues constantly. A pen test report with one Critical and nothing else is almost always scoped to hide the rest of the surface area.
4. AI training data without licence basis in writing
The seller's lawyers should already have this in a binder. If they don't, you'll be the buyer who finds it during post-close litigation.
5. Customer churn concentrated in the last quarter
Often a sign of a known-bad release, a competitor product launch, or a contract clause coming up for renewal that the seller is hoping you'll close before they have to renegotiate.
6. Deployment frequency below weekly
Healthy SaaS deploys daily. Below weekly in a 50+ engineer team is a strong signal of architectural debt that has slowed feature velocity to the point where the team has given up trying to ship faster.
7. Manual processes hidden in the runbook
Read the on-call runbook. Any step that says "ask Alex" or "rerun the script in /home/alex" is a key-person risk that doesn't appear on the org chart.
8. Vendor concentration above 40%
A foundation-model provider, payment processor, or hosting provider above 40% of variable cost is a single point of pricing failure. Sellers know this; they will not volunteer the concentration calculation.
9. Source-code repositories that are read-only
A target that has migrated to a new VCS but kept the old one read-only is hiding history. Insist on full history access or a written explanation for the migration.
10. Eval infrastructure that is one engineer's laptop
For AI startups specifically. If the evaluation harness lives on a single laptop, you cannot trust the model's reported performance, and you cannot replicate it post-close.
11. Customer support tickets that the engineering team doesn't see
Two-tier support where engineers are insulated from customer issues is correlated with the worst post-close NPS surprises we've audited.
12. A 'roadmap' that is just the last two quarters' missed features
A target whose roadmap is the carry-over of unshipped features is a target whose engineering team is not in control of its own delivery. The post-close investment to fix this is consistently underestimated.
Frequently asked
Should any of these kill a deal?+
Rarely on their own. Two or three together, especially when combined with founder-engineer dependency, usually justifies either a repricing or a structural protection — a deferred element of consideration, a retention package, or an indemnity carve-out.
How do we surface these efficiently?+
Architecture session first (90 minutes), then a focused evidence request driven by what surfaces. Reference calls last. Order matters — the architecture session redirects the rest of the diligence.
If you're reading this as…
Related guides
Tech Due Diligence
SaaS Tech Due Diligence Checklist — 2026 Buyer's Guide
The 47-point technical diligence checklist VCs and corp dev teams use on SaaS targets. Architecture, security, AI exposure, key-person risk, scoring rubric.
Tech Due Diligence
Tech Due Diligence on an AI Startup — Buyer's Playbook
How to run technical diligence on an AI-first startup. Training data, model moat, inference economics, vendor lock-in, and the questions the seller will dodge.
Data Rooms
VDR Audit Trails: A Buyer's Guide to Data Room Logs
Discover what constitutes an audit-grade VDR audit trail. Learn why generic logs fail scrutiny and what to demand from your data room provider.
Tech Due Diligence
A Guide to Open-Source License Audits in Tech Due Diligence
Understand the risks of open-source software in M&A. This guide covers copyleft contamination, SBOMs, and SCA scans for effective tech due diligence.
About the author
Founder, Beyond M&A · Creator, Lens
Twenty years inside tech due diligence, integration and AI-native deal tooling. Built and exited tech businesses, led Tech DD on 150+ deals across PE, corp dev and strategic buyers, and now ships Lens — an AI workspace for diligence teams.
Further reading on our network
Beyond M&A
Beyond M&A Insights
Field notes on what we see in the deal market — red flags, valuations, AI exposure.
Beyond M&A
Beyond M&A — Tech Advisory
Practitioner-led advisory for VCs and corporate development teams running complex deals.
Technology Due Diligence
Sample Tech DD Report
Anonymised buy-side technical diligence report — structure, evidence, risk scoring.