Built by Andrew Edmond · technical diligence across dozens of Amazon deals · CTO, Woot.com

Technical due diligence, read from the repository itself.

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.

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.

Compare the tiers on Pricing