Know what you are buying before you sign.
Pitch decks describe the product the founders intend to have. Technical due diligence tells you what actually exists: how the software is built, who can maintain it, what it will cost to scale, and whether the "AI" in the pitch is a real capability or a thin wrapper around someone else's model.
Technical due diligence is not one size fits all
A seed cheque and a full acquisition carry very different risks. We match the depth of the review to what is at stake, so you do not pay for an acquisition-grade audit on an early round.
| Early-stage investment | Growth round | Acquisition or merger | |
|---|---|---|---|
| Core question | Can this team build what they claim? | Will the platform survive the next stage of growth? | What are we inheriting, and what will it cost to integrate? |
| Code access | Walkthrough, sample review | Repository review of key areas | Full repository and infrastructure access |
| Team assessment | Founders and first engineers | Engineering leadership and key-person risk | Retention risk, knowledge concentration |
| AI scrutiny | Is the AI real and defensible? | Model costs, data rights, vendor dependency | IP in AI-generated code, model licences, data provenance |
| Typical timeframe | Days | 1 to 2 weeks | 2 to 4 weeks |
Timeframes are indicative and depend on how quickly the target company provides access and answers questions.
How we test AI claims and AI-generated code in due diligence
Almost every company raising money now describes itself as AI-powered, and much of its code was written with AI assistance. Neither is a problem in itself. Both need checking, because the risks are new and rarely covered by a traditional technical review.
Is the AI proprietary, or a prompt around a public API?
We trace what happens when a user triggers an AI feature. A wrapper can still be a good business, but it should not be valued like owned models or unique data.
Who owns the data the models depend on?
We check whether training and retrieval data was licensed, collected with consent, or scraped, and what customer contracts say about using it.
What happens to margins at scale?
Inference and GPU costs often grow faster than revenue. We model unit economics at several times current usage, not just today's bill.
Was AI-generated code reviewed by anyone senior?
Large volumes of unreviewed AI-written code tend to show up as duplicated logic, missing authorisation checks and tests that assert very little.
How exposed is the product to a single model vendor?
Pricing changes, deprecations or policy shifts at one provider can break a product overnight. We look for abstraction and fallback options.
Are evaluation and safety practices real?
We ask how the team measures AI output quality and handles failures. "We test it manually sometimes" is a finding worth pricing in.
Beyond the code: the six areas that move valuation
Architecture and scalability
Whether the system can handle the growth in the business plan, and roughly what re-engineering would cost if it cannot.
Code quality and technical debt
A sampled review of maintainability, test coverage and debt hotspots, translated into an estimate of drag on future delivery.
Security and compliance
Authentication, secrets handling, data protection and the gaps a regulator or enterprise customer would spot first.
Team and key-person risk
How knowledge is spread across the team, how they use AI in delivery, and what happens if one or two people leave after the deal.
IP and open-source licences
Code ownership, contractor assignments, licence obligations in dependencies, and provenance questions around AI-generated code.
Infrastructure and running costs
Hosting, third-party services and AI inference spend, and whether costs scale sensibly with customers.
From signed NDA to decision-ready report
Agree the questions
Day 1We agree with you what the deal hinges on, so the review answers your investment thesis rather than producing a generic audit.
Request pack and access
Days 1 to 3A focused document request, read-only repository and cloud access, and interviews scheduled with the technical leads.
Review and interviews
Main phaseHands-on code and infrastructure review, supported by AI tooling to map large codebases quickly, with every finding verified by a senior engineer.
Report and debrief
Final daysA written report ranking findings as deal-breakers, price adjustments or post-deal fixes, plus a call to walk your team through it.
Independent technical due diligence, on either side of the table
Our technical due diligence is designed for angel investors, investment funds and companies acquiring a software business. We also help founders with a pre-diligence review, so they can fix the obvious issues before an investor finds them and control the story when questions come.
Our founder has spent more than 18 years in technology, has founded, built and exited his own ventures, and has led technology at startups and global enterprises. He has been on both sides of a deal, so the report focuses on what changes the decision rather than filling in a generic checklist.
The review is there to give you an accurate picture, not to set up follow-on work. If a deal sits outside what we can assess well, such as deep hardware or specialised scientific software, we will say so at the start and suggest where to look instead.
Questions we often hear
What is technical due diligence?
Technical due diligence is an independent review of a company's technology before an investment or acquisition. It covers architecture, code quality, security, the engineering team, IP and running costs, and it translates technical risk into terms that affect valuation and deal structure.
How long does technical due diligence take?
A light review for an early-stage round can take a few days, a growth-stage review commonly takes one to two weeks, and an acquisition review often runs two to four weeks. The biggest variable is how quickly the target provides access to code, systems and people.
How do you assess a startup's AI claims during due diligence?
We look at what actually runs in production: which models are used, whether they are owned or rented, what data they depend on and who holds the rights to it. We also model inference costs at scale and check how the team evaluates AI output. The aim is to separate defensible capability from marketing language.
Is AI-generated code a risk in an acquisition?
It can be. The main concerns are unreviewed code with security gaps, duplicated logic that slows future work, and unclear provenance if tools reproduced licensed code. AI-assisted development done with proper review is normal and healthy, so we assess the team's process rather than penalising AI use itself.
Can founders get technical due diligence done before raising?
Yes, and it is often money well spent. A pre-diligence review surfaces the issues investors will ask about, gives you time to fix or explain them, and helps you present your architecture and AI strategy with confidence.
Related reading and tools
Get a clear technical picture before you commit.
Tell us about the company, the deal stage and your timeline. We will reply within 24 hours with a suggested scope, depth of review and the questions we would focus on.
Working with companies globally · Response within 24 hours