Technical due diligence workspace
An investor asks to review a target company's code. The company connects its own repositories and chooses what to share. The investor receives a graded report in which every conclusion can be followed back to the files behind it, and gaps are reported as gaps.
- IndustryInvestment diligence
- EngagementIn-house product build
- StatusIn active development
What it does
An investor needs to know what they are buying before the money moves. This workspace answers that question with a graded, evidence-backed report on the target company's codebase, instead of a summary the reader has to take on trust.
It runs as a two-party flow. The investor opens the review and sends an invitation; the target company connects its own account and selects exactly which repositories enter it. Nothing is analysed that the company did not hand over.
Diligence that could not show its work
Technical reviews tend to arrive as conclusions, with no way for the reader to check them or to see what was never looked at.
Conclusions without evidence
A written review says a codebase is risky or sound. The reader cannot follow that judgement back to a file, or tell whether the reviewer opened that part of the code at all.
Access asked for before trust exists
The target company is expected to hand its source over early in a deal, in one piece, with no say in what is shared and no record of where it went.
Gaps that read like clean results
When a check does not complete, a report tends to average around the hole. Missing evidence and a good result end up looking identical on the page.
A workspace built around what it can prove
Four things the investor and the target company can rely on.
Access on the company's terms
The investor opens a review and sends an invitation. The target company connects its own account and picks which repositories enter the review, so access is granted on the company's terms.
- The company decides what is shared, repository by repository
- Nothing is analysed that was not handed over
- Working copies deleted when the run ends
A report that says what it could not check
The review runs as a sequence of checks. A check that could not complete is identified in the report and lowers its completeness.
- Security findings are verified before they are reported
- Dependencies and leaked credentials are checked
- Change history, architecture and technical debt in one report
Grades with the evidence attached
The codebase is graded across quality, security, architecture and maintainability, each grade with the measurements behind the letter.
- Findings point at the file and the line
- Security findings come with a reproducible proof
- Technical debt is costed by a published model, with the working shown
Honesty written into the report
The report is built to be checkable. Its readiness checklist has three states: pass, fail, and insufficient evidence.
- An incomplete run withholds the overall grade
- Absent findings are reported as insufficient evidence, never as a clean result
- Conclusions are supported by evidence from the source files
What it changes about a review
Investors receive an evidence-backed report with its coverage made clear.
Traceable
Every conclusion
A grade can be followed back to the files and lines that produced it, and the reader can see which model wrote the section they are reading.
Your hardware
Where analysis runs
Analysis can run on the operator's own hardware, so sensitive code does not have to leave it to be reviewed.
Never averaged
Missing evidence
A gap is reported as a gap. When coverage is incomplete the report withholds the overall grade.
Reviewing a technical investment?
We build diligence tooling that shows its evidence and runs where you need it to run. Tell us what you are evaluating.
Talk to us