Service
Read the code,
not just the deck.
Technical due diligence as a fixed-scope review of one to two weeks. It ends with a written report with severity ratings, an estimated cost for every finding, and a debrief call for your investment committee.
We agree the scope. Read access to the code and the infrastructure, under NDA.
01 - The situation
The deck sells a platform. Nobody read the code yet.
You commit capital to software that your team did not build. A technical review closes that gap before you sign.
What the deck does not show
- One founder holds every production credential, with no documented recovery plan.
- A feature in the demo turns out to be a manual process behind a screen.
- The architecture in the deck does not match what runs in production today.
- The next round finds the technical debt that this one missed.
What the review gives you
- We read the code and the infrastructure before you sign the term sheet.
- We check every feature in the deck against the system that runs today.
- We interview the engineers alone, without a founder in the room.
- You get a written report with a severity rating on every finding.
02 - What you get
Three things reach your committee
Not a verbal impression and not a one-page memo. A report with a rating and a cost on every finding.
01
A written report with severity ratings
Every finding gets a rating, from critical to low, with a cost estimate to fix it.
What it is
We write down what we find in the code, the architecture, and the infrastructure. Each finding carries a severity rating and an estimate of the time and the money to fix it. The report separates findings that should change the terms from findings that are normal for the stage.
Why it matters
Your investment committee reads one document, not a collection of opinions. A finding only helps the deal when it carries a cost.
02
A review of the code, architecture, and infrastructure
We check whether the system as it exists today supports the growth in the plan.
What it is
Under NDA, we take read access to the repository and the infrastructure. We review the source code quality, trace the architecture against the load that the plan assumes, and check the security posture and the infrastructure cost.
Why it matters
You learn what breaks first at ten times today's load, before that load becomes your problem.
03
Team interviews and a debrief call
We talk to the engineers directly, then we walk your committee through the findings.
What it is
We interview the technical team without a founder in the room. We ask what stops if one person leaves the team. A debrief call closes the engagement, so your committee can ask its own questions directly.
Why it matters
You hear what the code alone does not tell you. Your committee gets a direct answer, not a forwarded document.
03 - How it runs
One to two weeks, four steps
The scope stays fixed from the first day. Every step ends with something your committee can read.
We agree the scope. Read access to the code and the infrastructure, under NDA.
Scope and access
We agree the scope and take read access to the repository and the infrastructure. An NDA is standard.
Code and infrastructure review
We review the source code, the architecture, the security posture, and the infrastructure cost. We interview the technical team.
Severity ratings
Every finding gets one of four ratings, from critical to low, with an estimated cost to fix it.
Report and debrief
You receive the written report. A debrief call walks your investment committee through the findings.
05 - Questions
Common questions
- How long does a technical due diligence review take?
- A typical review takes one to two weeks, from access to a finished report. We fix the scope before we start. It covers the code, the architecture, the infrastructure, and interviews with the technical team, under NDA from day one. The review often pays for itself in the negotiation alone. The main delay is usually how fast the target company grants access and answers follow-up questions.
- Why is there no case study for a due diligence engagement?
- A due diligence engagement runs under NDA by its nature. We do not publish the target company, the findings, or the report from any review. Our public case studies show the review capability instead. They are full write-ups of products we designed, built, secured, and shipped, with real numbers. Our own products also carry independent scrutiny, including a security audit across 113 requirements and a separate penetration test.
- What does a software due diligence report cover?
- The report covers the source code quality, the architecture, the security posture, and the infrastructure cost. Investors sometimes call this a code audit or an architecture audit. We run it as one review, not two. We check whether the architecture supports the growth that the business plan assumes. Every finding carries a severity rating, from critical to low, with an estimated cost to fix it.
- Do we need a technical person on the investment committee to read the report?
- No. The report opens with a summary that a non-technical partner can read in five minutes. Every finding carries a severity rating and a cost estimate, so the committee can weigh it without a translator. A debrief call covers any question that the report does not answer. This replaces an internal CTO due diligence process for funds that do not have one on staff.
- At what funding stage should we commission a review?
- The right scope depends on the stage, so we size a pre investment technical review to fit the deal. A full review fits best at Series A and later, because the round already assumes that the product can grow at scale. At seed, a lighter review makes sense mainly when the technology itself is the investment thesis. At pre-seed, a structured conversation with the founders usually tells you enough.
- What backs your review capability, beyond the report itself?
- We hold ISO 9001:2015 and ISO/IEC 27001:2022 certification, for quality management and information security. We shipped more than 20 products of our own over 18 years, so we recognize the failure modes from the inside. One of our own products passed a security audit across 113 requirements. Another went through an independent penetration test and an accessibility audit. We apply the same standard to a review that we apply to our own code.
06 - Related
Other services
Most engagements combine two of these. Start where the risk is highest.
Send us the data room.
Talk to us before the term sheet. A review takes one to two weeks and often pays for itself in the negotiation alone.