This is a synthetic avatar. The words are mine; the face is generated. Borehole reports on AI provenance in codebases, so it would be odd not to declare our own. The screens shown are the product's own, from a real report.

Transcript

Hi, I'm Andrew Edmond. I was CTO of Woot.com, and at Amazon I led technical diligence and integration planning across dozens of deals from 2024 to 2026. I built Borehole because the question never changes. What are we actually buying? How good is the technology, where are the risks, and will the team fit? Deals compress months of work into weeks, sometimes days. A demo won't show you the risk, neither will a conversation or an architecture diagram somebody drew that morning. Meanwhile, the git history has had the real answer all along. Who wrote what, how carefully it was reviewed, what was tested, and whether a secret was ever committed. It's just too much for a person to read in the time a deal allows. Borehole reads it for you. You get a rating on each dimension of technical diligence, and every finding points to the commit, the file, and the line behind it. It tells you how much of the code arrived in commits that declare an AI agent, and it says plainly what a repository can't answer. The roadmap, the team's intentions, whether anyone watches the alerts. Those become the questions to take into the room. For each finding, it also tells you what a buyer's engineer will try on the running system, so you can check it first. And if a finding is wrong, the owner can answer it right beside it, on the same page. Your source code never reaches us. For a private repository, the collector runs on your own machine and sends facts, not code. Run it with dry run first, and it shows you every byte before anything is sent. Or run it inside a Confidential VM in your own Google Cloud project, and the report can prove the facts weren't edited on the way. Every report carries a code anyone can verify. Try it free on any public GitHub repository at borehole.dev. When the report isn't enough, that's where I come in: onsite with your team, ready to directly assess the risks and closing conditions required to get the deal approved, or to help build the case that the deal is not right for your company. Thanks for watching.

Andrew Edmond

2026 – present: AELaboratories, independentBorehole
2024 – 2026: Principal, M&A Technology and Engineering Integration, AmazonPrincipal technical leader for Amazon Corporate Development
Before: CTO, ValderaCTO, Woot.com, an Amazon companySenior Director of Software Development, Twitch, founding its Seattle site engineering organisation
Education: Computer Engineering, USC
Based: Southern SpainRemote, with onsite as the deal requires. In English.

Seven dimensions, learned the expensive way.

What the deals taught

Nearly thirty years in engineering leadership before any of this was about diligence. The M&A work started in early 2022: as CTO of Woot.com I worked closely with Amazon's Corporate Development team through several acquisitions and divestitures, on the side of the table that inherits whatever the diligence missed. From late 2024 I led technical diligence and integration planning for that team across dozens of deals.

The pattern repeated. The risks that mattered were rarely the ones in the data room. They were in how a team worked, what they knew they had deferred, and whether anyone left could safely change the system. And they were answerable in the first afternoon, if you knew where to look.

What Borehole does

Knowing where to look is the thing this tool encodes. It runs the checks a senior reviewer runs in that first afternoon, without a language model. Where a check cannot decide, the report says so rather than guessing. On a paid survey of a public repository, a language model then reviews the findings against the code and withdraws one it judges the code contradicts; the report says which and why.

When the review runs

The review runs after a paid survey of a public repository, before the report is stored. It never runs on a private repository, a collected survey, a free reading or a re-read; a re-read keeps an earlier review's withdrawals only where the finding and its evidence are unchanged. If the review is switched off, fails or runs out of time, the report arrives as the checks wrote it. The review is a language model's reading of the findings against the code, and it can be wrong. It never adds a finding, never raises a band, and never removes a finding from a proven check or an advisory that affects the surveyed version.

It is free on a public repo and €249 at launch on a private one.

Working with me

An engagement starts where the survey finishes: the team interviews, the levelling, the incident history, and the integration plan against your stack. Two to four weeks, on site or remote, adaptable to your timeline, ending in a plain-English risk register an investment committee can read. I can run it end to end, or work alongside your own engineers.

Buy side, for private equity and growth investors. What you are about to own, what it will cost to absorb, and which of your systems it lands on.
Sell side. What a buyer's adviser is going to find, early enough that you can still fix it.
After close. The integration plan, run by the person who wrote the assessment.

Run a free repo survey Start a conversation

The full framework →