Technical due diligence, read from the repository itself.
Built by Andrew Edmond · technical diligence across dozens of Amazon deals · CTO, Woot.com
Technical due diligence, read from the repository itself.
Run the repo survey View the library
Paste any repository URL from GitHub, GitLab, Azure DevOps, Bitbucket, Codeberg, Gitea or SourceHut. Or see one first: prometheus/prometheus →
106 diligence checks, seven dimensions
History and working tree, rated on the dimensions a deal team cares about. What the code cannot answer becomes a question for the room.
Every finding cites its evidence
The commit, path and lines it rests on, or, when something is missing, what was looked for.
Your repository stays on your machine
Public repos need no access at all. For private ones, the collector reads it there. What it sends: never whole files; facts and short excerpts of up to 120 characters where a check matched.
Sell side
Find the gotchas before a buyer does
In a real process, an investment bank puts someone like me in front of your engineering team weeks before anyone else sees the code. Every problem found then is a problem you still have time to fix. Found later, it is a discount.
Normally: your bank's technical adviser, in the weeks before a data room opens, once. Here: months earlier, on your own private repo, as many times as it takes to close the findings out.
Survey your own private repository →
Buy side
Know what you are walking into
Your diligence team has a fixed number of hours and more targets than hours. A repo survey is a cheap first read — enough to tell which targets deserve the expensive attention, and which questions to open with when they get it.
Normally: an in-house diligence group, engaged once a deal is real. Here: before it is real, on every name in the pipeline.