Tech Due Diligence Red Flags

In dozens of tech DD engagements, certain red flags come up again and again. These aren’t necessarily deal-breakers - but they signal risk that needs to be quantified and priced into the deal.

Here are the most common and impactful red flags we find.

Code & Architecture Red Flags

1. No Automated Tests

If there’s no test suite, every change to the codebase is a gamble. No tests means no safety net - bugs reach production, regressions go unnoticed, and developers are afraid to refactor. This is the single most common red flag we encounter.

2. Monolith Without Boundaries

A monolithic architecture isn’t inherently bad, but a monolith with no internal boundaries - no modules, no clear separation of concerns - becomes exponentially harder to maintain as it grows. Changes in one area break unrelated features.

3. Outdated Dependencies

Running on end-of-life frameworks, unpatched libraries, or deprecated language versions. This creates security vulnerabilities and makes it increasingly difficult to hire developers who want to work with the technology.

Infrastructure Red Flags

4. No Infrastructure as Code

If the production environment was set up manually and isn’t documented in code, it’s a single point of failure. Recreating the environment after a disaster becomes a guessing game.

5. No Monitoring or Alerting

If the team doesn’t know when something breaks until a customer reports it, the operations maturity is low. This leads to extended outages, slow response times, and eroded customer trust.

6. Single Point of Failure

One server, one database, one region, one provider - if any single component going down takes the whole system offline, the business is exposed to unnecessary availability risk.

Team & Process Red Flags

7. Key-Person Dependency

When one developer holds all the knowledge - the architecture, the deployment process, the business logic - the company has a critical vulnerability. If that person leaves, the knowledge goes with them.

8. No Code Review Process

If code goes directly from a developer’s laptop to production without peer review, the quality assurance is entirely dependent on individual discipline. This is how bugs, security issues, and inconsistencies accumulate.

9. Missing Documentation

No architecture diagrams, no API docs, no runbooks, no onboarding guides. Institutional knowledge exists only in people’s heads. This makes every team change (hires, departures, reorgs) a high-risk event.

10. Slow or Manual Deployments

If deploying takes hours, involves manual steps, or only happens monthly - the team can’t iterate quickly, can’t fix bugs fast, and can’t respond to market needs. This slows the business.

What Red Flags Mean for the Deal

Red flags don’t automatically mean “don’t invest.” They mean:

1. Quantify the cost - How much will it cost to fix? Factor this into your offer price.
2. Assess the timeline - How long will remediation take? Factor this into your growth projections.
3. Evaluate the team - Can the current team fix these issues, or do you need to hire?

For a complete assessment framework, see our checklist. To understand how these findings factor into valuation, compare tech DD vs financial DD.

Looking to avoid these issues before investors find them? See our guide for founders.