Technical Due Diligence

The tech story can make or break a deal.

You’re about to invest in a company. The deck looks good. The numbers make sense. But the product runs on a system nobody outside the founding team fully understands — and the CTO says everything is “fine.”

Is it?

Technical debt isn’t always visible in the financials. Fragile infrastructure doesn’t show up in the P&L. A codebase held together by one critical developer who might leave — that’s a risk that belongs in the due diligence, not in the post-closing surprises.

That’s what Technical Due Diligence is for.

Who this is for

• Investors and funds evaluating a company before closing a deal
• Acquirers who need to understand what they’re actually buying on the technical side
• Founders preparing for a fundraising round who want to know their vulnerabilities before investors find them

The report is written to be read by non-technical decision-makers. No jargon. Clear conclusions. Actionable numbers.

What gets reviewed

Code quality and technical debt How maintainable is the codebase? How much of it was written in a rush and never cleaned up? Are there critical security vulnerabilities? What does the debt cost to address?

Infrastructure and operations What does it actually cost to run? Is it robust — or is there a single point of failure waiting to happen? What are the external dependencies and vendor lock-in risks?

Team and processes Who knows the system? What happens if they leave? How is development organized? What’s the release process, and does it work?

Critical risks and deal-breakers What could prevent the business from scaling? What’s the biggest technical risk that’s not in the data room?

Modernization cost estimates If things need to be fixed, how much will it cost? Not a rough guess — a structured estimate with assumptions stated clearly.

What you get

A structured written report with:

• Executive summary — the verdict in plain language, for non-technical readers
• Risk matrix — what’s critical, what’s significant, what’s manageable
• Technical debt assessment — what exists, what it costs to carry, what it costs to fix
• Infrastructure review — reliability, costs, dependencies
• Team assessment — key-person risk, organizational maturity
• Modernization estimates — what it would cost to bring the system up to standard
• Recommendations — whether to proceed, renegotiate, or walk away

The report is written to be read by a CFO, a partner, or a board member — not just a CTO.

Format and timeline

One week.

Access is needed to: the codebase (read-only), infrastructure documentation, architecture diagrams if they exist, and one or two technical conversations with the target company’s team.

The report is delivered at the end of the week. A debrief call is included to walk through the findings.

Remote engagement by default. On-site possible if the situation requires it.

Investment

€8,500 — fixed price

One week of work. One structured report. One debrief.

No surprises on the invoice.

A note on confidentiality

Technical due diligence involves access to sensitive code and systems. I work under NDA as standard. The report is shared exclusively with the commissioning party.

I don’t share information between clients, and I don’t use what I see in one engagement to inform work on another.

Timing

Due diligence has deadlines. If you’re working toward a closing date, reach out early — I’ll tell you honestly whether I can fit your timeline.