Reading an Acqui-Hire Target's Engineers From Their Public Work

Before you approach a small startup about an acqui-hire, you need to decide two things from the outside: is this engineering team worth buying, and which engineers actually carry the product. This teardown is for engineering managers, technical founders, and technical sourcers running that call. It works one target end to end from public signals alone - roster, per-engineer contribution ranking, the load-bearing person, the flight risks, and a go/no-go - all before the first conversation.

Every current public answer to "how do I diligence an acqui-hire" is an inside-access checklist: system-design interviews, contract review, reference calls. Those only start after both sides are already talking. By then you have signalled intent and lost leverage. This guide runs the assessment on public evidence first, so you never pay the acqui-hire premium on a team whose product was built by one person who has already left.

What are you actually buying: team or IP?

Run this test before anything else: is the differentiator in people's heads or in defensible IP? If the value is a patent, a dataset, or a code asset that survives without its authors, you are doing IP diligence and grading engineers is the wrong exercise. If the value walks out the door with the people, you have a team asset, and everything below applies.

The framing that makes this load-bearing comes from practitioner Karich & Associates: in an acqui-hire "the team is the asset," while "the company, the product, the code, the customer list" are "secondary considerations or cleanup items." The purchase price is "a hiring premium wrapped in a transaction, calibrated to lock in the people the acquirer wants for two to four years." The mechanism underneath is one line: "people depreciate. IP compounds." Wikipedia's summary is blunter still - the acquired product "is of at most secondary interest and is often killed shortly after the acquisition."

So the classification is not academic. It decides whether the load-bearing person is your asset or your risk. Confusing the two wastes the whole exercise, which is the first failure mode below.

The worked example I carry through this guide: a seed-stage startup with a public GitHub org, a flagship repo that maps to the shipped product, and eight names on the org member list. The one-line thesis after Step 1: I would be paying a hiring premium to lock in whoever actually wrote the core modules, not for the code, which the acquirer would likely fold or retire.

The premium you are pricing against

An acqui-hire is priced per head, and the going rate is far above a standard hire. That gap is the entire reason this diligence exists: you only clear the premium if the talent cannot be replaced at the standard-hire floor.

The named benchmarks converge. Elad Gil's High Growth Handbook: for a true team buy, companies "typically pay $1 million to $3 million per engineer, designer, and product person." Cooley GO widens the floor: buyers express price "on a per-head or per-engineer basis, and the going rate seems to be anywhere from a few hundred thousand to two million per head." AI talent breaks the scale entirely, valued at $5M to $10M-plus per senior researcher in recent deals. Retention packages commonly vest over three to four years, so the money is a lock-in, not a lump sum.

Against that, the standard-hire anchor: the SHRM 2025 Benchmarking Report puts the average cost per hire at $5,475 for nonexecutive positions and $35,879 for executive positions. A separate SHRM report gives a median of $1,300 nonexec. Either way, the acqui-hire premium is two to three orders of magnitude above a normal req.

The defensible comparison is $1M-$3M per engineer against a $5,475 average cost per hire. One secondary glossary asserts a flat "25x to 50x premium," but that figure is internally inconsistent with its own numbers, so I treat it as unverified and do not use it.

Resolving the full engineering roster

The roster is the org member list plus every core repo's contributor graph, cross-mapped to real identities and cleaned of outside contributors. No single primary how-to exists, so I assemble it from GitHub's own docs and a peer-reviewed method.

GitHub exposes the contributor list directly: "you can view the top 100 contributors to a repository in the contributors graph." But it warns that "merge commits and empty commits aren't counted as contributions for this graph," and some insights only render for repos under 10,000 commits. Org membership and teams live in a separate view. So the roster is never just the contributor graph - you combine the graph, the org member list, and the pull-request reviewers.

Separating employees from drive-by contributors is the harder part. The academic anchor is a GitLab study: among 2,956 contributors, researchers "detected 210 current GitLab employees split in 37 teams," and found "commit activity alignment proves to be a reliable way to tell GitLab employees from external contributors." Employees cluster around working hours and around the same modules over time; outsiders spike once and vanish.

In my worked example, the org member list showed 8 people, but the flagship repo's contributor graph listed 24 names. Commit-activity clustering collapsed those 24 to 6 who committed on a regular cadence against a long tail of one-off external patches. Two of the 8 org members had never committed to the flagship repo at all - they worked on internal tooling in another repo. Net roster for the core product: 6 engineers.

One caveat before you trust the list: co-authored commits and private or no-reply emails mean rosters are undercounted unless emails map to accounts. Commits on non-default branches never appear in the graph at all. That is the roster-undercount failure mode, and the fix is always to add PR reviewers and org members to the graph, never to rely on the graph alone.

De-aliasing before you count anything

Merge every person's multiple emails and handles into one row before you compute a single number. Skip this and you will hand yourself a falsely reassuring answer.

Here is why it is not optional. The World of Code research is explicit: "under-aliased ids split one person's work across several identities, so each holds fewer commits and the project appears to spread its knowledge over more people than it really does: an inflated, falsely reassuring bus factor." De-aliasing is monotonic. Merging identities can only ever move commits onto fewer people, never more. So it can only lower the bus factor.

That has a sharp practical consequence. Any target that looks pleasantly distributed before cleanup is exactly the target where cleanup will expose concentration. The distributed-looking team is the trap, not the safe bet.

De-aliasing only ever makes a team look worse, so the target that looks distributed is the one to check hardest.

In my example, the six-person core team looked like a healthy spread on first pass: no single author held more than 30% of commits. After merging two engineers who each committed under two different emails - one work, one personal - one of them jumped to 51% of all commits. The team was not distributed. It had one person and five helpers.

Contribution share and bus factor: two calculations, run both

Rank engineers with two documented methods, because they can disagree, and the disagreement is information. Trusting one is how you buy the wrong person.

The commit-share method gives the bus factor: "the minimum number of developers whose cumulative share first reaches 50% of the project's commits." The file-ownership method gives the truck factor, built on the Degree-of-Authorship metric: "to infer the authors of a file we use the Degree-of-Authorship (DOA) metric, which is computed using version history data, and to estimate the Truck Factor, we use a greedy heuristic," removing low contributors until fewer than half of files still have a knowledge owner.

They measure different things. Bus factor rewards raw commit volume; truck factor rewards owning the files that matter. A prolific committer who reformats code scores high on bus factor and low on truck factor. The person who wrote the hard core modules but committed less often can score the reverse. Run both and reconcile rather than trusting either.

Read that table before you panic at your own result. A bus factor of one is not an anomaly; it is the base rate. In the de-aliased 189.9M-project dataset, 96.48% of projects are a single point of failure. In a 133-project study, 46% had a truck factor of one and 28% had two. So finding one load-bearing person does not mean the target is broken. It means the go/no-go turns entirely on whether that one person is present and retainable.

In my example, bus factor and truck factor agreed after de-aliasing: the 51%-of-commits engineer also owned the majority of core files by DOA. When both methods name the same person, your confidence is high. When they disagree, treat the file-owner as the deeper risk, because owning the hard code is harder to replace than owning the commit count.

Flagging flight risk before you make contact

Read whether each key engineer is disengaging, and specifically whether the load-bearing person has already left, from public activity alone. This is the check that separates buying a team from buying nobody.

Flight risk is visible in public artifacts. Survival-analysis research on npm and RubyGems found developers more likely to abandon an ecosystem "do not engage in discussions with other developers; do not have strong social and technical activity intensity; communicate or commit less frequently." A GitHub dropout study of 206 users found off-hours work and support activity are moderating factors. And there is a clean operational line: a developer with "no commits for at least a year" is treated as having abandoned the project.

The stakes are highest for the concentrated person. Research on contributor disengagement found that "disengagements of contributors with a high share of commits lead to pronounced declines in throughput and acceptance." Losing the load-bearing person is not a dent; it is the product's throughput collapsing.

In my example, the load-bearing engineer was still committing weekly and still reviewing others' pull requests - active and anchored. Had she instead shown no commits for twelve months and gone quiet in discussions, the deal thesis would have collapsed: I would be paying a team-buy premium for a team whose product was one person who is now gone. That is failure mode four, and it is the most expensive mistake on this list.

Where Refolk removes friction here is the cross-source resolution: mapping a commit-author email to a current LinkedIn employer and a recent activity trend is exactly the tedious cross-mapping the roster step demands, run in plain English across the public GitHub graph, LinkedIn, and the open web at once.

Scarcity and geography change the premium more than headcount

Two facts decide whether the premium is defensible, and neither is team size: how scarce the skills are, and how deep the local hiring pool is. If you can re-hire the same skill at the standard-hire floor, do not pay the acqui-hire premium.

Scarcity first. In Refolk's index of professional profiles, US Staff Software Engineers with Rust number 125, against 705 for Go - Go talent is roughly 5.6 times more abundant at Staff level. A Rust-built core product cannot be re-hired at the $5,475 SHRM floor because the pool is thin, which is precisely what justifies the $1M-$3M per-engineer premium. A Go-built product of equal complexity is far more replaceable, and the premium is harder to defend.

Geography compresses your options the same way. In Refolk's index, the US founding-engineer pool is 4,321 against 609 in the UK - about 7.1 times larger. A UK target's team is far harder to reconstitute locally, which raises both retention risk and the defensible premium. A San Francisco target sits in the deepest pool there is, so unless the skills are scarce, walking away and hiring is a live alternative.

These figures come from Refolk's index and are published nowhere else. The interview-and-cut lever ties them together: because acquirers commonly interview the employees and reserve the right to cut those below bar, which lowers the price, a documented low bus factor lets you price only the load-bearing people rather than the whole headcount. You pay the premium for the one Rust owner who carries the product, and you interview the rest.

The procedure, start to finish

Here is the full sequence, in order, as I ran it on the worked example. Timings are rough and assume public data only.

One order disagreement to resolve inside Step 4 and 5: the file-ownership truck factor and the commit-share bus factor can rank people differently. Run both and reconcile rather than trusting one. When they name the same person, act with confidence; when they split, weight the file-owner.

Where this goes wrong

The methods above fail in predictable ways, and every one produces a false positive that reads as good news. This is the section to keep open while you work.

Two of these deserve extra weight. The private-repo problem is fatal to the whole exercise: a startup's core product may live in private repos while public GitHub shows only side projects, so you can grade the wrong codebase entirely and never know. Before you trust any ranking, confirm that public repo activity maps to the shipped product. If it does not, say so in the memo and treat the public signal as unavailable rather than dressing up a guess.

Spoofed authorship is the quieter trap. Git lets anyone set any name and email on a commit, so authorship is not proof of identity. The Verified badge, backed by GPG or SSH signing, is the only cryptographic proof a commit author is who they claim. On the critical commits that decide who your load-bearing person is, check for the badge before you name a name in a memo that will move money.

Before you call it a go

Run this checklist before you write the go/no-go memo or make any contact. Every item is a thing to verify, not a topic to consider.

The memo is a single decision: is the load-bearing person present, active, retainable, and above bar, and does the implied premium clear the standard-hire floor given the skill scarcity? In my worked example the answer was a qualified go - one active Rust owner who owned the core by both methods, in a thin skill pool, priced at the team level but with interview-and-cut rights on the five helpers.

Keeping the read current

A public read decays. Commit activity, employment, and repo visibility all change between the day you build the memo and the day you approach. Re-run the flight-risk step - Step 6 - within a week of first contact, because the whole thesis rests on the load-bearing person still being present. A twelve-month inactivity line that was green last quarter can flip, and a founding engineer who was committing weekly can go quiet the moment they line up their next move.

The one signal worth a standing watch is the load-bearing person's commit cadence and their departure from discussion threads. Both predict abandonment before a resignation is public, which means you can catch a key-person exit while you still have the option to walk. That is the entire edge of doing this work from public evidence first: you learn whether you are about to buy a team or buy nobody before you have spent a dollar or tipped your hand.