Skip to main content

Technical due diligence

When an investor or acquirer asks "is this company technically sound?", the answer is rarely a simple yes or no. My job is to turn that fuzzy question into a clear, ranked, decision-grade read. Here's how I do it.

The four dimensions I assess​

1. Architecture. Is the system designed for where the business is going, or just where it's been? I look at scalability on the axes that matter, the cost curve as load grows, single points of failure, and how much of the design is deliberate versus accidental.

2. Code & engineering practice. Quality, test coverage where it counts, CI/CD, and the bus-factor risk of critical knowledge living in one head. I'm less interested in style and more in whether the team can change the system safely and quickly.

3. Team & organization. Can the team that built this also evolve it? Levels, key-person risk, hiring health, and whether the engineering culture will survive the next stage of growth.

4. Risk & compliance. Security posture, data handling, licensing and IP, and any regulatory exposure that could become a deal-breaker after close.

Red flags I weigh heavily​

  • A demo that works but a codebase no one can confidently change.
  • "AI" that turns out to be a thin wrapper with no data moat or evaluation.
  • A single irreplaceable engineer holding the whole system together.
  • Cloud costs growing faster than revenue with no architectural explanation.
  • Security and compliance treated as "later" when customers will demand it soon.
  • A roadmap that requires a rewrite the team is quietly avoiding mentioning.

What you get​

A written report, readable by both technical and non-technical stakeholders, with:

  • An overall confidence rating and the reasoning behind it.
  • Risks ranked by severity, each with likelihood and potential impact.
  • A remediation list — what it would take to address each one, and roughly how much effort.
  • A debrief call to walk through the findings and answer the "so what do we do?" questions.

The goal isn't to kill deals or bless them. It's to make sure you're making the decision with the technical truth in front of you.

This is the framework behind the ENG-TDD engagement. If you have a deal or an internal bet you want an independent read on, let's talk.