What Reverse Acqui-Hires Actually Diligence

TL;DR: Every piece of content on “acqui-hire due diligence” is a law firm or an M&A shop writing about deal structure and valuation math. None of it describes what a technical reviewer actually inspects when the codebase itself isn’t the thing being bought — which is exactly the shape of the 2024–2025 wave of reverse acqui-hires (Microsoft/Inflection, Amazon/Adept, Google/Windsurf). In a reverse acqui-hire, the buyer is licensing IP and lifting out people, often leaving the company and its repo behind. That flips what “technical diligence” even means: instead of grading the code, the reviewer is mapping which humans hold the system in their heads, whether the codebase can survive their departure, and what “IP” actually refers to once you separate it from the repo. If you’re a founder on the receiving end of one of these offers, here’s what actually gets inspected, and what to have ready before the reviewer opens your repo.

What a reverse acqui-hire actually is

A normal acquisition buys the company: the entity, its equity, its contracts, its codebase, its cap table. A reverse acqui-hire is a different shape entirely — the buyer licenses the technology (usually non-exclusively) and hires away the people who built it, while the original company keeps existing as a separate legal entity, often with a much smaller team and a repriced business.

The pattern got its name and its playbook in March 2024, when Microsoft paid Inflection AI roughly $650 million to license its technology and hired most of its technical staff, including co-founder Mustafa Suleyman, who became CEO of the newly formed Microsoft AI division. Microsoft didn’t buy Inflection. Inflection kept existing, recapitalized, and pivoted (Bloomberg). Amazon ran the same play three months later: a licensing deal for Adept’s agent technology and select datasets, reported at $330 million plus a $100 million retention pool, paired with hiring roughly 80% of Adept’s team, including CEO David Luan (TechCrunch, Semafor). And in July 2025, after OpenAI’s $3 billion acquisition of Windsurf collapsed inside a 72-hour window, Google structured a $2.4 billion non-exclusive license for Windsurf’s technology and hired its CEO, co-founder, and top researchers into DeepMind — while Cognition separately acquired the rest of the company, its IP, its brand, and its ~$82 million ARR business (TechCrunch).

The pattern in all three: the buyer isn’t primarily after the repo. They’re after the people who can rebuild the capability inside their own stack, plus enough of a license to say they didn’t take it for free. The regulatory upside is real too — these deals have repeatedly avoided the antitrust review a formal acquisition would trigger, though the UK’s CMA has since started designating some of them as mergers anyway (Fortune, TechCrunch). But from the engineering side, the interesting part isn’t the antitrust maneuvering — it’s that the diligence process for these deals is inspecting something almost nobody writes about, because almost nobody who writes M&A content has sat in the room doing it.

Diligence when the code isn’t the asset

Standard technical due diligence — the kind I’ve described for round-stage investors — treats the codebase as the asset and asks whether it’s worth what the deck claims. A reverse acqui-hire reviewer is answering a completely different question: if we hire these twelve people and license this technology, what do we actually get, and does it survive the move? That reframes almost every check.

Key-person risk mapping, taken literally instead of as a line item. In round diligence, “key-person risk” is a paragraph in the memo. In reverse acqui-hire diligence, it’s the entire point of the exercise — the buyer is choosing which specific humans to make an offer to, and the technical reviewer’s job is to map, file by file, which of those humans actually hold each critical system in their head. Not “who’s a good engineer” — who is the one person who can explain why the retrieval pipeline routes around the vector store for a specific class of query, and is that person on the list of people getting an offer. If the person who understands the load-bearing part isn’t being hired, the deal’s technical value just dropped, and a competent reviewer will flag that before the term sheet firms up. I’ve written about how I evaluate this kind of depth when hiring a staff engineer at an AI startup — the same signal, run in reverse: you’re not grading a resume, you’re mapping who actually understands the hard part of the system, because that’s the asset, not the title on their badge.

Codebase disposability assessment. This sounds harsh, and it’s meant to. Since the code is often explicitly not what’s being acquired — the company keeps it, or it gets left behind, or a separate buyer takes the shell (as Cognition did with Windsurf) — the reviewer is asking a question round diligence never asks: is this codebase disposable, and if the acquiring company has to rebuild the capability with the hired team instead of the repo, how much time does that cost? That’s a very different exam than “is this code well-architected.” A brilliant, tightly coupled codebase that only the departing team can safely touch scores worse on this axis than a mediocre but well-documented one, because the buyer isn’t keeping either — they’re keeping the people, and the question is how much of what those people know is trapped in code only they can read versus knowledge that travels with them regardless of which repo they’re standing in front of.

What “IP” means once you separate it from the repo. In round diligence, “IP” mostly means the code and the patents, if any exist. In reverse acqui-hire diligence, the license is being drafted around a much broader and fuzzier set of assets: the eval suites and benchmark harnesses (how do you know the system works, independent of any specific implementation), the data pipelines and the rights to the training/eval data that feeds them, the prompt libraries and scaffolding patterns that took months of iteration to get right, and the tacit operating knowledge of how the model actually behaves in production versus in the paper. None of that lives in git log. A reviewer here is building an inventory of what’s licensable that isn’t code — because the license terms will be drafted against that inventory, not against the repo. If your evals only exist as a Jupyter notebook one person runs locally, or your data-rights paper trail is “we’re pretty sure we can use this,” that’s the finding that shows up in this diligence, not “your test coverage is thin.”

Contribution-graph forensics, but reading for a different signal. I still open the commit history first, same as I would for a funding round. But I’m not reading it to ask “does the team own the IP they’re claiming” — in a reverse acqui-hire, ownership is usually clean and undisputed, since the company built the thing itself. I’m reading it to ask who actually wrote the parts that matter, cross-referenced against exactly who’s on the offer list. If the person whose commits touch the core inference logic every week isn’t getting hired, and the reviewer didn’t already know that, that’s a material finding — the buyer is about to pay for capability they’re not actually acquiring. This is the same forensic technique as round diligence, aimed at a completely different conclusion.

How this is genuinely different from round diligence

I’ve written before about surviving technical due diligence as an AI founder — that post is about the investor’s pre-check before a funding round, where the reviewer is asking whether the team in the room owns the IP they’re claiming and whether the business is worth the price on the term sheet. Keep those two mental models separate, because conflating them will make you prepare for the wrong exam.

Round diligence is fundamentally a valuation exercise wrapped in a technical inspection — the reviewer is trying to find the gap between what you claim and what’s true, because that gap re-prices the round. Reverse acqui-hire diligence is a feasibility exercise — the reviewer already knows roughly what they’re paying and who they want, and the technical review is checking whether the acquisition actually delivers the capability once you subtract the entity, the equity, and (often) the repo. One is asking “is this company worth $X.” The other is asking “if we hire these specific twelve people and license this specific technology, do we actually get what we think we’re buying, or did the value live somewhere else.” Different question, different artifacts, different findings.

What founders should actually prepare — and what not to scramble on

If you’re a founder fielding one of these offers, or advising a team that is, here’s where the prep effort should go, roughly in the order it moves the outcome:

1. Have an honest map of who understands what. Not a resume roundup — an actual accounting of which humans hold which systems in their heads, and how much of that knowledge is written down versus tribal. This is the single artifact a reverse acqui-hire reviewer will be building anyway; having it ready and accurate is the biggest trust signal you can offer, and it directly shapes who gets an offer and at what number.

2. Separate your IP inventory from your repo. Write down, explicitly, what exists outside the code that a buyer might value: eval harnesses, data-rights documentation, prompt and scaffolding libraries, operational runbooks for how the system actually behaves in production. If this only exists as tribal knowledge, that’s the gap to close before the process starts, not the codebase’s test coverage.

3. Don’t scramble to make the codebase look pristine. This is the opposite instinct from round diligence, and it trips people up. If the code isn’t the primary asset, spending your last two weeks on a cleanup sprint or a documentation push aimed at impressing a code reviewer is effort spent on the wrong exam. Spend it on the IP inventory and the honest key-person map instead.

4. Be straight about who’s leaving and who’s staying. The reviewer will find out anyway which of the technical staff are taking the offer and which aren’t. A founder who volunteers this clearly — including which capabilities walk out the door and which stay behind with the shell company — reads as more trustworthy than one who lets the reviewer discover it. The same principle runs through everything I’ve written about how trust functions as the actual operating system of a technical organization: the reviewer isn’t just pricing your technology, they’re pricing whether your account of your own team is accurate, and that judgment follows you into whatever comes next — including, often, the people who stayed behind and are now rebuilding under a new plan.

5. Get your data-rights paper trail in writing before you’re asked. If any of your training data, eval data, or user data has an ambiguous provenance story, that ambiguity becomes the buyer’s problem the moment they license it — which means it becomes a heavily negotiated clause, or a walk-away, before it becomes their problem. Bringing a clean, honest data-rights memo unprompted is worth more here than almost anywhere else, because the license is being drafted around exactly this.

6. Decide in advance what happens to the company that’s left. Every one of the public examples — Inflection, Adept, Windsurf — kept existing as a distinct entity after the licensing deal closed, with a smaller team and a different mandate. If you’re the founder staying behind rather than the one taking the offer, that’s a distinct planning problem from the diligence itself, and it deserves its own honest answer before the ink dries, not an improvised one after.

None of this is about having a flawless codebase. It’s about knowing, in advance and accurately, what a reviewer is actually going to find when they map your team instead of your repo — because in this kind of deal, the team is the repo.

If you’re navigating one of these

Reverse acqui-hires are still rare enough that most founders — even technical ones who’ve been through a normal fundraise or acquisition before — haven’t seen this specific diligence pattern up close. The questions are different, the artifacts that matter are different, and the instinct to over-prepare the codebase actively works against you. If you’re fielding one of these offers, or trying to figure out what happens to the team and the company that’s left behind afterward, that’s worth a conversation before the term sheet is final, not after.