Technical due diligence services for investors and acquirers

A madewithlove technical due diligence covers five pillars: team and leadership, process, written communication, engineering, and problem and solution. In practice that means interviews with the founders and engineers, a review of the codebase and architecture, and an assessment of security, scalability, and the way the team actually ships. We pull the findings together into a single written report, so you get a rounded view of the technology and the people behind it rather than a shallow checklist.

No. Financial due diligence and quality of earnings work examine revenue recognition, ARR quality, churn cohorts, and the accounts, and that is a job for an accountancy firm. A SOC 2 or ISO 27001 assessment certifies that security controls exist and are operating, which is a job for a compliance auditor. Technical due diligence answers a third question: whether the software, the architecture, and the engineering team can carry the business plan you are underwriting. Most SaaS deals need more than one of the three. We do the engineering one, and we will say so plainly when what your deal actually needs is an accountant or a certification body.

Around two weeks end to end. We validate the key questions with you, run the interviews (up to eight one-hour interviews), carry out an in-depth code review, then fact-check the findings and debrief you. We scope the exact timeline up front and work to your deal timetable.

Investors, acquirers, and boards. Venture capital firms use it to price risk before a seed or series A/B investment. Acquirers use it to understand what they are buying before a merger or acquisition closes. Boards commission it when they want an independent read on the technology behind a company they are backing. In each case you are relying on an objective third party rather than the target company's own account of its technology.

You get a written technical due diligence report. It sets out our findings across the five pillars, flags the technical risks and their likely impact, and highlights the strengths worth protecting. It is written to be read by an investment committee or a board, so it stays clear about what matters for the decision in front of you. We talk you through the report so you can act on it with confidence.

We started doing due diligence because investors and VCs asked us to, and we've now audited 190+ startups worldwide. We don't rely on magical formulas or famous influencers' opinions. Because we have run engineering teams and built software ourselves, we assess the code, the architecture, and the team the way a technical partner would, and we give you an honest read on the risks rather than a reassuring score.

Yes. A growing share of the codebases we assess were written largely with AI tools. We verify quality, security and maintainability with the same five-pillar methodology, and we add the questions specific to AI-built software: whether the generated code is covered by tests, whether anyone reviews what the tools produce, and whether the team can still explain how the system works.

Yes, as a standard part of every audit. We look at how the team uses AI today and check it against what is in the repository, because what shows up in commits, pull requests and documentation is regularly more than what came up in the interviews. We also look at whether guardrails and review discipline exist, where source code is allowed to go and whether those controls are proportionate to the other risks we find, how dependent the product is on a single model provider, whether spending on AI matches the adoption we can observe, and whether the codebase is documented well enough for AI tools to work on it safely.

More often a mismatch than an absence. A pattern we keep seeing: serious money going into AI infrastructure and experimentation while practical adoption in the product stays thin, alongside strict rules to keep source code away from public models while broad production access, shared credentials and secrets sitting unencrypted on machines get far less attention. That goes in the report as one finding about alignment, with the evidence behind it, because what has to change is the order of priorities rather than the tooling.