Answer first: what makes a technology red flag deal-killing?
A technology due diligence red flag becomes deal-killing when it threatens the buyer's ability to own, operate, scale, secure, or integrate the asset behind the investment thesis. Most findings do not kill deals. They change valuation, SPA protections, completion evidence, or the first 100-day plan.
The practical question for PE, VC, and corporate M&A teams is therefore not "is there a risk?" It is: what evidence proves the risk, how severe is it, how likely is the downside, and what decision follows before final diligence closes?
This page keeps one canonical owner for red flags in technology due diligence and focuses on deal-killing technology due diligence red flags across software, SaaS, and tech-enabled manufacturing targets.
If you are still defining the assessment, compare these warning signs with how a technology due diligence review works so the red-flag scan stays tied to evidence, scope and buyer decisions.
Deal-killer, price / terms, or 100-day plan?
Investor teams should force each finding into a decision bucket. That prevents generic checklist sprawl and makes escalation decisions explicit.
deal-killer
Test: The finding undermines the core thesis, transfer of value, customer continuity, or legal ownership.
Escalation decision: Pause or escalate to IC/legal before signing; require proof, seller remediation, or a walk-away decision.
price / terms
Test: The issue is material but bounded if cost, timing, owner accountability, and residual risk are understood.
Escalation decision: Use valuation adjustment, holdback, warranty, indemnity, condition precedent, or budgeted remediation.
100-day plan
Test: The buyer can own the remediation after close without changing the thesis or completion risk.
Escalation decision: Convert into named 100-day owners, budget, milestones, and board reporting.
SaaS, software and manufacturing red flags for final diligence
For software and SaaS acquisitions, the most useful red-flag review is answer-first: which issue is severe, how likely is the downside, what evidence proves it, how it changes the deal, and which SPA / terms response belongs in the transaction plan.
Roadmap-critical code is fragile
severity: High
likelihood: Likely when defect history, low test coverage, and release incidents cluster around revenue-critical services.
Evidence to request: Recent defects, test coverage, deployment records, roadmap dependency map, release incidents, and refactoring backlog.
deal implication: Roadmap velocity and retention assumptions may be overstated.
SPA / terms response: valuation adjustment or completion evidence if the growth thesis depends on near-term delivery.
SaaS metrics hide platform stress
severity: High
likelihood: Likely when cloud cost per customer, support load, churn reasons, and uptime evidence diverge from ARR growth.
Evidence to request: Cloud spend by product/customer cohort, gross margin bridge, support tickets, churn reasons, uptime and incident history.
deal implication: Gross margin, scalability, and retention assumptions may need repricing.
SPA / terms response: require model rebase, target operating metrics, and funded 100-day remediation before underwriting expansion.
Security debt blocks enterprise customers
severity: Medium
likelihood: Likely when high vulnerabilities, missing control evidence, weak logging, or incomplete GDPR practices are unresolved.
Evidence to request: Pentest and vulnerability history, access controls, incident process, customer security questionnaires, audit commitments.
deal implication: Enterprise expansion, insurance, compliance, and customer trust assumptions may slip.
SPA / terms response: specific warranties, holdback, retest milestone, or condition precedent for the highest-risk controls.
Knowledge is concentrated in one founder or engineer
severity: High
likelihood: Likely when deployments, architecture decisions, privileged access, and customer escalations all route through one person.
Evidence to request: Commit history, deployment logs, access ownership, architecture documentation, on-call rota, customer escalation history.
deal implication: Integration, continuity, and value-transfer risk rise sharply if the person leaves or is unavailable.
SPA / terms response: retention plan, documented handover, access transfer, and completion milestones before close.
Core IP or open-source ownership is unclear
severity: Critical
likelihood: Likely when contractors, agencies, AI components, or legacy founders contributed without clean assignment evidence.
Evidence to request: PIIA records, contractor assignments, dependency manifests, licence scan, third-party model/data terms, repo ownership trail.
deal implication: Ownership uncertainty can delay completion or block future sale, integration, or enterprise licensing.
SPA / terms response: make clean assignment evidence a completion condition or explicit indemnity before value transfers.
Tech-enabled manufacturing data cannot be trusted
severity: High
likelihood: Likely when MES, ERP, PLC/OT, quality, inventory, or production dashboards depend on undocumented manual reconciliation.
Evidence to request: MES/ERP integration map, downtime logs, quality records, OT access model, batch traceability, data lineage and manual overrides.
deal implication: Yield, working-capital, service-level, and synergy assumptions may not be supportable.
SPA / terms response: valuation adjustment, warranty around critical data, and 100-day plan for integration hardening.
If the target is subscription-led, use the SaaS acquisition red-flags framework to test customer retention, data/IP, operating metrics and founder dependency before deciding whether to reprice, protect or walk away.
What the evidence changes in valuation, SPA and remediation
Red flags are decision-useful only when they change a buyer action. A valuation adjustment belongs where remediation cost, growth delay, margin pressure, or reliability risk can be estimated. SPA / terms protection belongs where the buyer needs seller promises, holdback, indemnity, or completion evidence. A 100-day plan belongs where risk is real but owned and executable after close.
Need this translated into a scoped decision framework? Open a M&A tech DD scope to define your risk model, evidentiary asks, and next steps.
When deal execution begins, your team may move from scoping to a post-acquisition 100-day review to convert this evidence into an execution plan.
1. The CTO Can't Articulate Their Own Technical Debt
Ask any technical leader to describe the three things they would fix if they had the budget and time. It is a simple question, and credible teams should be able to answer it with evidence and trade-offs.
When the response is defensive, vague, or suspiciously polished, that is a signal. It usually means one of three things: the debt has not been seriously thought about, the team has been coached to present well rather than honestly, or the person leading the technical function does not have a clear enough view of what they have built.
You want a CTO who can name a real weakness, explain the impact, and describe the next practical fix rather than only responding with architectural diagrams and a roadmap slide.
Technical debt exists in every mature codebase. What matters is whether the team understands it, has a plan for it, and has been managing it actively rather than deferring it indefinitely.
2. No Monitoring, No Alerting, No Observability
If a business cannot tell you how their system performs in production, they do not actually know whether it is working.
Basic observability means: centralised logs you can search, meaningful alerts that fire when things go wrong, and some form of application performance monitoring. These are normal operating controls for a customer-facing software business.
The absence of observability is often a proxy for how operationally mature the team is. It suggests things break and get fixed reactively rather than problems being caught early. It also makes post-acquisition integration significantly harder, because you are inheriting a black box.
Ask to see how they would diagnose a production incident right now. If the answer involves trawling through unstructured server logs or asking one specific person who holds all the knowledge, that tells you something.
3. Key Person Risk Is Severe and Unacknowledged
Every business has people who matter. That is normal. The red flag is when a disproportionate amount of operational knowledge lives in one or two individuals, and the business either has not noticed or does not consider it a problem.
Warning signs include:
- A single engineer who wrote most of the core systems and is the only person who can operate them
- A CTO who has not documented anything because they "don't need to, they know it all"
- Deployment or release processes that only one person runs
- One person managing all third-party relationships and credentials
The bus factor question is worth asking directly: if this person left tomorrow, what breaks, and how quickly could you recover?
Key person risk is not unusual in smaller businesses. What is concerning is when there is no awareness of it, no plan to address it, and no documentation that would reduce the dependency. That combination suggests the risk has been growing unmanaged for a long time.
4. The Deployment Process Is Manual and Infrequent
How software gets from a developer's machine to production tells you a lot about how the team operates.
A mature team can explain its release cadence, controls and rollback process clearly. In many healthy software businesses that means frequent automated deployments, staging environments and changes that do not require heroics.
A team with serious operational problems tends to deploy infrequently, manually, and with a degree of anxiety that is visible when you ask about it. "We do a big release every couple of months" should prompt follow-up questions. So should "deployments usually take a day to coordinate."
Infrequent releases accumulate risk. Large batches of change going out together are harder to test, harder to roll back, and harder to attribute when something breaks. They also tend to indicate a weak engineering culture around collaboration and continuous improvement.
5. Security Has Been Treated as Someone Else's Problem
In smaller tech businesses, security is often deferred. There are always more urgent things to build. The result is usually a pattern of known issues that never quite made it to the top of the backlog.
Red flags to look for:
- No recent penetration test, or a pentest that was completed but findings were never prioritised
- Admin accounts and production access shared across the team without a clear access management process
- API keys and secrets embedded in code or stored in documents rather than a secrets manager
- No MFA on critical systems
- No documented response to previous security incidents
The presence of known vulnerabilities is not always fatal. What matters is whether the team knows about them, takes them seriously, and has a plan to address them. If the response to security questions is dismissive or defensive, that is a concern.
GDPR compliance is worth probing specifically in any business that processes personal data. The cost of a serious data protection failure post-acquisition falls squarely on the acquirer.
6. The Architecture Has Grown Without Design
There is a meaningful difference between an architecture that was designed and then evolved, and one that accumulated organically over several years without any deliberate thought.
The latter tends to present as:
- Multiple overlapping systems doing roughly the same thing, never rationalised
- Integration patterns that are inconsistent across the product (REST here, webhooks there, direct database access somewhere else)
- A data model that reflects the history of the product rather than its current shape
- No clear ownership of different parts of the system
This matters for two reasons. First, it increases the maintenance cost of the product. Changes in one area have unpredictable effects in others. Second, it makes integration after acquisition significantly harder, because you cannot simply connect systems to something that has no coherent structure.
Ask to be walked through the architecture at a system level. A team that understands what they have built can explain it clearly. A team that does not usually talks about individual features rather than how things fit together.
7. Contracts and Licences Are Not in Order
Technology risk is not limited to the code. It extends to the commercial arrangements that underpin it.
Check these areas carefully:
IP ownership. Has all work by contractors and agencies been properly assigned to the company? IP that sits with a former agency or freelancer is a material risk.
Open-source licence compliance. GPL and AGPL components create obligations that affect how the software can be distributed and sold. This is not always well understood by the businesses using them.
Software licences. Are all licences properly scoped? Enterprise licence agreements sometimes include per-user or per-CPU terms that the business has grown beyond without adjustment.
Vendor lock-in. What happens if the main cloud provider or infrastructure partner is no longer viable? What are the exit costs?
These issues rarely kill deals on their own, but they create remediation costs that should factor into valuation. An incomplete IP assignment, for example, may require legal work to resolve before the business can be sold on.
8. The Team Talks About Technical Problems in the Past Tense
When engineers describe challenges their business has overcome, that is often a good sign. When every technical risk is framed as something that is "all sorted now" without any substantive explanation of how it was sorted, that warrants scepticism.
Healthy engineering teams are usually candid about current imperfections. They know what is not working well. They have a list of things they would fix if they had more time. They are honest about the trade-offs they have made.
When a team presents as perfect, or when the management presentation appears too consistent with the technical narrative, it is worth finding ways to probe beyond the prepared answers. Talking directly to engineers rather than only to the CTO often produces a more honest picture.
9. Cloud Spend Is Not Understood or Controlled
In a cloud-hosted product, infrastructure cost tends to grow with scale. That is expected. What is less acceptable is a team that does not understand their own bill or has no view on how costs will scale as the business grows.
Ask for a breakdown of current monthly cloud spend. Ask what it was twelve months ago. Ask what they expect it to be at 2x and 5x current scale.
Common problems include:
- Unoptimised database configurations running at many times the necessary cost
- Development and test environments running at full scale around the clock
- Reserved instance or committed use discounts never pursued despite consistent usage
- Untracked data transfer costs that inflate the bill unexpectedly
Cloud spend is often an area where meaningful cost reduction may be achievable post-acquisition. It is also an area where projections in a deal model can be materially wrong if the business has not managed it properly.
10. Nobody Can Find the Documentation
Documentation is easy to skip and hard to justify investing in. Most engineering teams end up with less than they should have.
The red flag is not the absence of documentation per se. It is the combination of weak documentation with other signs of low operational maturity.
If the system is complex and only one or two people understand it, and there is no documentation to reduce that dependency, the knowledge transfer risk is real. If runbooks do not exist for common operational tasks, every incident becomes a first-time problem. If new engineers take six months to become productive because there is nothing written down, that constrains your ability to scale the team.
Ask what a new engineer would read on day one. Ask where the architecture documentation lives. If the answer is "you would just ask the team," that is worth noting.
How to Respond to Red Flags
Finding red flags in a technology assessment does not necessarily mean walking away. It means understanding what the issues are, how much they cost to fix, and whether the deal economics still make sense once those costs are factored in.
A few principles:
Be specific about the remediation cost. A codebase with significant technical debt is not a reason to abandon a deal. It is a reason to quantify the work required, factor that into valuation, and confirm that the acquirer has the capability to execute it.
Think about the team, not just the technology. Technology problems can be fixed. Culture and process problems are harder. A team that has been building in the wrong direction for a long time is a more significant risk than a team with known but understood technical issues.
Consider what post-acquisition looks like. Some businesses are acquisitions where the technology is the asset. Others are acquisitions where the technology is an enabler. The tolerance for technical risk is different in each case.
When to Bring in External Review
Experienced deal teams develop good pattern recognition over time. But technology assessment requires both breadth (across architecture, security, operations, people, and commercial) and depth (the ability to go beyond the pitch and actually probe the codebase and team).
An independent review also gives your investment committee a cleaner basis for decision-making. Where significant issues are found, a properly documented assessment provides the evidence needed to support valuation adjustments or post-closing commitments.
TechDD provides buy-side technology due diligence for PE and VC transactions. If you are running a process and want an independent view before close, get in touch.
FAQ
What are deal-killing red flags in technology due diligence?
Deal-killing red flags are technology findings that make the buyer doubt ownership, continuity, scalability, security, margin quality, or the core investment thesis. Examples include unclear IP ownership, severe key-person dependency, unfixable architecture constraints, inherited security liability, and cloud or operational costs that break the model.
How should a buyer separate deal-killers from price or 100-day issues?
Start with evidence, then classify each finding by severity, likelihood, buyer exposure, and reversibility. A deal-killer blocks the thesis or transfer of value. A price or terms issue can be handled through valuation adjustment, warranty, holdback, condition precedent, or funded remediation. A 100-day issue is manageable after close if ownership, budget, and timing are clear.
Which SaaS red flags most often change deal terms?
SaaS red flags that change terms include fragile roadmap-critical code, cloud costs growing faster than revenue, weak reliability evidence, security debt that blocks enterprise customers, unclear data or IP rights, and founder concentration around architecture, releases, pricing, or customer escalations.
What is a technology due diligence red flag in manufacturing deals?
For tech-enabled manufacturing, material red flags include unsupported MES or ERP integrations, fragile production data flows, undocumented automation logic, cyber exposure in operational technology, supplier-owned code, and reporting gaps that make yield, downtime, inventory, or quality assumptions hard to verify.
What evidence should buyers request for red-flag findings?
Buyers should request defect and incident history, release records, test evidence, cloud cost trends, uptime data, vulnerability and access-control evidence, IP assignment records, dependency manifests, architecture documentation, customer support signals, manufacturing integration maps where relevant, and roadmap dependency evidence.
When should a red flag become a SPA or completion item?
A red flag should move into SPA drafting or completion conditions when the buyer cannot verify the fix before close, when the cost or timing is material, or when the issue could affect customers, revenue, regulatory exposure, integration, business continuity, or the investment thesis.
Can TechDD help scope a red-flag review before confirmatory diligence?
Yes. A scoping call can define the target's highest-risk assumptions, evidence requests, pre-LOI screening options, confirmatory diligence scope, escalation decisions, and the transaction protections needed if material risks appear.