Can this three-way classification be made mechanical, or does it stay subjective?

It can't be fully mechanized, but a first pass on severity, remediability, and remediation cost/time reduces reliance on gut instinct. The final call should still go through a deal team or investment committee for sign-off. The domain catalog in this article is meant as a starting point for that first pass, not a substitute for judgment.

How do conditional findings actually get reflected in a deal?

Typically through one or a combination of: representations and warranties, closing conditions (CPs), an escrow, or a post-closing remediation plan with milestones. Which mechanism fits depends on whether the risk can be fixed before closing, whether it can be indemnified financially, or whether it can only be resolved operationally over time.

Is a deal with zero red flags a good sign?

Treat it with skepticism rather than relief. Every DD process has real limits — restricted code access, time-boxed interviews, withheld documentation — so a clean report more often reflects a shallow DD than a genuinely risk-free target.

The technical DD red flag catalog: sorting findings into walk-away, conditional, and acceptable

The hardest part of technical due diligence isn’t finding issues — it’s deciding what a given finding means for the deal. The same finding, “almost no automated tests,” can be a deal-breaker in one case and a minor, acceptable gap in another. This article lays out a framework for sorting technical DD findings into walk-away, conditional, and acceptable, along with a domain-by-domain catalog of common findings, how findings compound, and how the weighting shifts by investment stage. For the full technical DD framework, see technical due diligence overview and the seven evaluation dimensions; for a comprehensive checklist of what to check, see the full technical DD checklist for investors.

Why sort findings into walk-away, conditional, and acceptable

Many technical DD reports stop at listing issues. What an investment committee or deal lead actually needs is a call on whether a given finding threatens the deal’s viability. Sorting every finding into one of three buckets turns a list of observations into something a committee can act on:

Walk-away (deal breaker): remediation is technically, financially, or legally impossible, or the remediation cost exceeds the deal’s value. The finding undermines a basic premise of doing the deal at all.
Conditional: remediable, but should be reflected in the deal through a closing condition, representations and warranties, an escrow, or a remediation plan.
Acceptable: given the company’s business model, investment stage, and growth plan, the finding does not block proceeding as-is.

The key premise behind this framework is that the same finding can land in a different bucket depending on the company’s context. Classification isn’t primarily about how severe a finding sounds in isolation — it’s about whether it’s remediable given the specific company you’re looking at.

A domain-by-domain red flag catalog

The table below sorts common technical DD findings by domain into the three buckets. Treat it as a starting point: the right classification for any real finding depends on the target’s business model, investment stage, and the sensitivity of the data it handles.

Domain	Walk-away finding	Conditional finding	Acceptable finding
Code & architecture	Core logic is mostly AI-generated or copy-pasted, nobody can explain the design intent, and the person who could is leaving	Monolith is approaching scale limits, but management has a concrete replatforming plan and effort estimate	Test coverage is thin, but limited to low-change peripheral features
Infrastructure & operations	Production secrets sit in plaintext in git history and have never been rotated	Single-region or single-vendor dependency exists, but the migration cost and plan are documented	There’s cloud lock-in, but the migration cost is small relative to the business’s scale
Security	The company handles regulated data (health, finance) with none of encryption, audit logging, or vulnerability management in place	No penetration test has been run, but one is scheduled with a concrete timeline	Dependencies carry moderate vulnerabilities, but the exposure window is short and a patch plan exists
Organization & people	The one founding engineer who understands the core logic refuses to stay on post-acquisition, and there’s no knowledge-transfer plan	Key-person dependency is high, but a retention agreement and documentation plan are in place	Commit concentration is high, but the codebase is small enough that handoff is straightforward
IP & legal	GPL-family OSS is inseparably embedded in core functionality, creating a real risk of a source-disclosure obligation	No OSS license inventory exists, but an audit found no serious contamination and a remediation plan is feasible	Patent filings are thin, but the competitive edge comes from data or execution rather than technology

What walk-away findings have in common: the means or the person to fix it is gone

What links walk-away findings isn’t raw severity so much as a structural fact: the person, the time, or the legal option needed to fix the problem is no longer available. Most technical debt is remediable given enough time and money. What turns a finding into a deal-breaker is usually a key person leaving, or a legal fact pattern (like license contamination already baked into a shipped product) that closes off the remediation path entirely. See what technical debt actually is for a deeper look at how to evaluate technical debt on its own terms.

What conditional actually means in practice: it has to reach the contract

A finding classified as conditional only does its job once it’s reflected in the deal terms — not just written into a report. Depending on the nature of the finding, that might mean a closing condition (CP) requiring remediation before close, a representation and warranty backing it, an escrow to hedge it financially, or a post-closing remediation plan tracked against milestones.

When acceptable findings compound into a walk-away

The most commonly missed failure mode in this framework is that individually acceptable findings can compound into something that should be classified as walk-away. A report that lists findings independently, without checking how they interact, will miss this every time.

No tests (acceptable alone) + key-person dependency (conditional alone) + no design documentation: each is manageable on its own, but together they mean both “a way to verify the code is correct” and “a person who knows why it’s built this way” disappear at the same moment. When that key person leaves, development effectively stops. Two findings that were each conditional in isolation should be escalated to walk-away in combination.
No OSS license inventory (conditional alone) + planned expansion into a regulated market abroad (acceptable alone): minor for the current domestic footprint, but the missing inventory becomes a real blocker once expansion triggers a license audit that customary business practice in that market requires.
Single-region dependency (acceptable alone) + no defined SLA (acceptable alone) + the product being positioned as mission-critical infrastructure for the acquirer: both findings are fine in isolation for a business with low availability requirements, but combined, in a deal where the acquirer intends to run this product as part of its core infrastructure, they become a walk-away-grade business continuity risk.

In practice, after scoring findings individually, run a second pass that groups findings by the people, workflows, or customer segments they share — that’s where compounding effects surface.

Red flag weight shifts with investment stage

The same finding carries different weight depending on the stage of the deal.

Seed and early stage: because the product is still expected to pivot, findings about code quality and architectural maturity get a wide acceptable range. That said, a fundamental absence of security or legal controls around personal data or the use of investor funds should still be treated as a hard floor, regardless of stage.
Series B and growth stage: because scaling per the investment thesis is now central, structural scalability defects and key-person dependency carry much more weight. As product complexity grows, outsourced-code debt (no one internally capable of maintaining it) also tends to move from conditional toward walk-away.
Buyout and corporate M&A with post-merger integration in mind: because the acquired technology assets are meant to integrate into existing systems, legal risk (IP, licensing) and organizational continuity (retaining key people) carry the most weight. Contractual hedges like reps and warranties or escrow are more readily available in buyout structures, which widens the range that can be classified as conditional relative to a typical VC deal — but a miscalculated integration cost estimate quickly becomes walk-away material.

Given this stage dependency, a technical DD team needs more than a generic checklist — it needs to understand the specific investment thesis (what growth scenario the deal assumes) before it can weight findings appropriately.

Summary

A technical DD red flag, by itself, is just an observation. Sorting it into walk-away, conditional, or acceptable — and layering on compounding effects and stage-dependent weighting — is what turns it into something an investment committee can act on. What matters isn’t how severe a finding sounds in isolation, but whether the person, the means, and the time needed to fix it are still available in that specific company’s context.

For the risk patterns that commonly surface after closing, see 10 technical risks that surface after investment; for the full evaluation framework, see technical due diligence overview and the seven evaluation dimensions. If you’d like an outside perspective on classifying and weighting red flags for a specific deal, reach out through TiedPro for investors or contact us.