Technology Due Diligence

What I do differently

Most technology due diligence is written from the outside looking in. It often reads well, but it misses operational reality. I take a different approach because I have been in the operating seat for years. I have led technology teams through fast growth, poor legacy systems, complex integrations, and high-pressure investor timelines. I know what is fixable, what is cosmetic, and what can quietly destroy value post-close.

I have integrated 22 acquisitions as CTO of a PE-backed group. I have seen what good documentation looks like and what fake confidence looks like. I know how teams present architecture under pressure. I also know where to look when an answer sounds polished but does not stand up to practical scrutiny.

My work is built for investment decisions, not academic debate. I focus on what affects deal value, integration risk, and execution certainty. If the product can scale with sensible investment, I say so. If there is hidden fragility that will hit EBITDA after completion, I call it clearly. You get a view you can use in IC conversations, not just a technical appendix.

What I assess

Code and engineering quality: I review codebase structure, maintainability, testing discipline, and delivery practices. I look for concentration risk, brittle architecture, and the gap between what the team says it can deliver and what the code suggests is realistic.

Architecture and platform resilience: I assess whether the technical architecture fits the business model. Can the platform support growth in users, geographies, products, and integration complexity? I look at uptime patterns, dependency risk, observability, and disaster recovery maturity.

Security and compliance posture: I assess controls, access management, patch discipline, incident handling, and practical security behaviour across teams. I also review how security aligns to the company’s sector obligations and customer expectations.

Technology team capability: I evaluate leadership depth, retention risk, operating cadence, and execution culture. A business can have good engineers and still fail delivery because priorities, ownership, and governance are weak. I call that out early.

Scalability and technical debt: I identify where debt is strategic and manageable versus where it is already a commercial drag. Technical debt is not inherently bad; unmanaged debt without a credible roadmap is.

Product and roadmap reality: I test roadmap assumptions against engineering capacity, architecture constraints, and customer commitments. I assess whether roadmap claims are investable or optimistic.

Integration readiness: For buy-and-build environments, I assess data models, APIs, identity management, and shared service opportunities. Integration effort is frequently underestimated, and that can distort post-deal value creation plans.

My process and what you get

I run a focused process designed around deal timelines. First, I align with your deal thesis and value-creation assumptions so the diligence focuses on commercial relevance. Then I run structured document review and technical interviews with leadership and key engineers. Where needed, I sample code and architecture artefacts to validate claims.

You get a clear output: strengths, material risks, remediation options, and likely effort/cost bands. I avoid generic red-amber-green language and give practical judgement. You can use the output directly in investment committee discussion, negotiation strategy, and 100-day planning.

I am also available for management sessions to test response quality in real time. The goal is not to catch people out. The goal is to separate manageable challenges from value-threatening issues before capital is committed.

Who I work with

I work with PE deal teams, VC investors, and corporate M&A leaders who need an independent technology view they can trust. Most engagements are linked to buyouts, growth investments, add-ons, or pre-exit readiness.

I am typically involved where technology matters to valuation and execution: vertical software, compliance platforms, data-heavy products, and operationally complex services businesses with material technology dependence.

Two-sided experience

I have been the CTO being assessed and the advisor doing the assessing. That matters. I understand what management teams are balancing under deal pressure, and I know how investor questions land in practice.

It also means I can distinguish between a team that is transparent about real issues and a team that is masking structural problems behind confident language. I know what good looks like — and I know the red flags that cost investors millions.