Who this is for
I work with venture capital and private equity funds, corporate development teams and family offices that are about to invest in, or acquire, a technology company. Typical moments:
- A term sheet is signed and you have a few weeks to confirm the technology is what it appears to be.
- The company's valuation rests on AI capabilities you cannot easily verify.
- You need to know whether the platform will survive the growth in the business plan.
- A portfolio company is struggling and you want an independent view of why.
What I assess
| Area | Key questions |
|---|---|
| Architecture | Is it fit for the next three years of growth, or heading for a rewrite? |
| Code and delivery | How healthy is the codebase, and how safely and often does the team ship? |
| Scalability and reliability | What breaks at ten times the load, and what does fixing it cost? |
| Security and compliance | Are customer data and regulatory obligations handled properly? |
| Cloud cost | Do unit economics hold up as usage grows? |
| Data and AI | What is genuinely proprietary, how is quality measured, and who owns the data? |
| Team | Key-person risk, leadership depth and the hiring the plan really needs |
AI due diligence
AI claims are now in almost every pitch, and they are hard to check from the outside. I look at what is built in-house versus what is a thin layer over a public model API, how the company evaluates quality, what the data rights and provenance look like, and what inference costs at the volumes in the plan.
I also look at defensibility. A product whose only advantage is a prompt is easy to copy. A product built on proprietary data, a well-designed knowledge graph or a strong evaluation discipline is not. My RAG to production checklist sets out the signals I look for in an AI system that is ready for real users.
My approach
- Scope with you. Agree the questions that matter for this deal and the depth required.
- Review documents and access. Architecture docs, repositories, cloud accounts, incident history and the roadmap.
- Interview the team. CTO, senior engineers and product, with your agreement and theirs.
- Test the claims. Read the code, check the infrastructure and examine how AI quality is measured.
- Report. A risk-rated, plain-language report with an executive summary, estimated cost to fix, and deal-relevant recommendations.
- Debrief. A walkthrough with your investment committee, and optionally with the company.
What you get
- An executive summary that fits on one page.
- Red, amber and green ratings across each area, with evidence.
- Estimated effort and cost to address material issues.
- Questions to raise in negotiation, and conditions worth considering.
- A 100-day technology value-creation plan, if you proceed.
Red-flag reviews for early-stage deals can be completed in days. Full reviews usually take one to three weeks.
Red flags I look for
- A single person holds the system in their head. No documentation, no second engineer who understands the core, and a founder who still deploys by hand.
- "We will rewrite it after the round." Sometimes true and sensible, often a sign the current architecture cannot carry the plan.
- Cloud spend growing faster than revenue. Usually a symptom of missing cost ownership or an architecture that scales badly.
- AI quality measured by anecdote. No evaluation set, no baseline, no tracking across releases.
- Unclear data rights. Training or retrieval on customer data without clear contractual permission.
- Security as a future project. Shared credentials, no audit logging, no incident history because nobody is looking.
- Release fear. Infrequent, large deployments and a team that avoids touching certain parts of the code.
None of these automatically kills a deal. They do change the price, the conditions and the first hundred days. My job is to make them visible early and put a realistic cost on each.
Green flags
Good signs are just as useful to an investment committee. I look for small, frequent releases, monitoring that the team actually checks, architecture decisions that are written down, sensible cloud cost per customer, and an engineering leader who can explain trade-offs without jargon. In AI companies, the strongest signal is a team that can show its evaluation results and explain what it does when quality drops.
What I need from you
A good review depends on access more than time. Ideally I get read access to the main repositories and cloud accounts, the architecture and security documents that exist (however rough), recent incident reports, and an hour each with the CTO and two or three senior engineers. Everything is handled under NDA, and findings are shared only with the people you name. If access is limited, I scope the review honestly and flag what could not be verified.
Confidentiality
Deals are sensitive. I work under NDA, keep notes and findings off shared drives you do not control, and never discuss one target with another. I also do not take advisory roles that would conflict with a review I am doing.
Relevant experience
I assess companies the way I would want my own work assessed, as someone who builds. I have designed and scaled systems handling more than a million transactions a day, built production RAG and agent systems with LangChain and LangGraph, and built a self-hosted AI platform on Kubernetes. That hands-on background makes it hard to hide a weak architecture from me, and easy to recognise a strong one.
After the deal, I can stay on as an advisor or fractional CTO to the portfolio company. For deals in the Gulf, see my UAE practice. You can read the case studies for examples of the problems I help companies fix.