Technical due diligence red flags
The technology issues that most concern investors are the ones that create inherited cost, risk or dependency: knowledge concentrated in a few people, a platform that cannot scale with the plan, debt that blocks the roadmap, security without evidence, unclear IP ownership, and a gap between what management says and what the evidence shows. Few of these stop a deal on their own. They change the price, the terms and the buyer's confidence.
A red flag is not the same as a problem
Every business has technology problems, and buyers know it. A red flag is a signal that the risk is larger than it looks, or that management does not know about it. The same issue can be amber in one business and red in another, depending on whether it is understood, sized and being dealt with.
The red flags
1. Management's account does not match the evidence
What the buyer sees: The leadership presentation describes a modern, well-run platform. The interviews, code and incident history describe something else.
What it signals: Either management does not know the true position, or is not saying. Both make a buyer re-examine every other claim.
Before a deal: Get an independent view early, so the story the board tells is the one the evidence supports.
2. One person holds the platform
What the buyer sees: A single engineer, often the founding CTO, is the only one who understands core systems or holds production access.
What it signals: Continuity risk after completion, and a negotiating position for that individual.
Before a deal: Spread knowledge and access over 12 to 18 months. See key person dependency.
3. Nobody can explain the architecture
What the buyer sees: No current diagrams, and different people describe the system differently.
What it signals: The platform has grown without design, and change is likely to be slow and risky.
Before a deal: Document the architecture as it is, and agree it across the team.
4. The platform has never been tested at the scale in the plan
What the buyer sees: The growth plan assumes volumes the platform has never handled, with no evidence it can.
What it signals: Hidden investment may be needed to deliver the forecast.
Before a deal: Test under realistic load and fix the constraints that matter to the plan.
5. Technical debt blocks the roadmap
What the buyer sees: Roadmap items that the forecast depends on keep slipping because of the state of the code.
What it signals: The revenue plan is less likely to be delivered on time or on budget.
Before a deal: Separate debt that blocks the plan from debt that does not, and fix the former. See technical debt and company valuation.
6. Security without evidence
What the buyer sees: Policies exist, but there are no access reviews, penetration tests, remediation records or incident history.
What it signals: Controls may not work in practice, and liabilities could transfer with the business.
Before a deal: Put evidence behind existing controls and close material gaps.
7. Unclear IP ownership
What the buyer sees: Core code was written by contractors or agencies without clear assignment of IP, or open-source licences conflict with how the product is sold.
What it signals: The buyer may not be acquiring everything it thinks it is.
Before a deal: Review contracts and licences, and put assignments in place well before a sale.
8. SaaS in name only
What the buyer sees: Many customers run on bespoke versions, forks or single-tenant deployments.
What it signals: Margins and scalability look worse than the revenue suggests, and every release costs more.
Before a deal: Make customer-specific work visible and bring it back towards one product.
9. Hosting costs that grow faster than revenue
What the buyer sees: Infrastructure spend rises sharply with each new customer.
What it signals: Gross margin may erode as the business grows.
Before a deal: Understand the cost drivers and show a credible path to efficiency.
10. Delivery that cannot be seen
What the buyer sees: No release history, no incident records and no delivery measures.
What it signals: Nobody can tell whether the team is predictable, so the roadmap cannot be trusted.
Before a deal: Start measuring now. A year of data is far more persuasive than a claim.
11. Unsupported technology
What the buyer sees: Core components are past end of life, with no upgrade path planned.
What it signals: Security exposure and a forced migration after completion.
Before a deal: Plan and budget the upgrade, and start it if the timeline allows.
What turns amber into red
Buyers are generally more forgiving of problems than of surprises. The same issue concerns them far less when management can show that it is:
- Known: identified before the buyer found it.
- Sized: with a view of impact, effort and cost.
- Managed: with an owner, a plan and progress to show.
That is the purpose of Technology Exit Readiness: finding these issues while there is still time to deal with them.
Find them before a buyer does
A ClearView assessment reviews the business against the same ground in two weeks, and sets out which issues matter and in what order to fix them. If you are an investor looking for these signals in a target, see technical due diligence.
Would a buyer find any of these in your business?
ClearView tells you in two weeks, while there is still time to fix them.