Hello there, folks. Thanks to everyone tuning in again.
Last issue we put real numbers on technical due diligence. This one is about the risk those numbers keep circling back to: the single person the whole platform quietly depends on.
In This Edition…
- How to find the one engineer who knows everything, in a first management meeting
- The sixth name: the engineer who can sink the platform might not even work there (Juan Resendiz)
- The 90-day plan that removes the risk without losing the person
- For subscribers: the money conversation, and what it does to the price
Let me start with the most honest version of this I can give you, which is that the key person has, more than once, been me.
Early on I worked at a fintech. I designed the systems. I built the MVPs, most of which reached production by accident rather than by plan. I built the infrastructure. I maintained the data pipelines. I wrote the client-side tooling and the internal apps the ops team ran the business on. Not out of ego. Out of need, and a permanent shortage of time. When something had to exist by Friday, I was the person who could make it exist by Friday.
You know what that gives you. One person who knows everything, and nobody else with the room or the remit to learn it. It felt like being indispensable. It was really being a single point of failure with a payroll number. These days I'm more often on your side of it, the one brought in afterwards to unpick one of these. The shape barely changes deal to deal.
The sequence is always the same. You spot it in diligence. You price it at signing. You defuse it in the first ninety days after close, on the fund's clock, with retention you negotiated before you owned the problem. This issue gives you the spotting and the defusing in full, below. The pricing, the part that decides whether you overpaid, is for subscribers.
Why the org chart won't tell you
The org chart shows boxes and reporting lines. It does not show where the knowledge lives. On paper you have a team of six. In reality five of them are waiting on the sixth, and the sixth is the one answering Slack at 11pm. That asymmetry is invisible in everything management hands you, partly because management often can't see it either. The exhausted engineer rarely complains. They're usually a bit proud of it.
So you can't read this off a headcount. You go looking, and it takes about ten minutes.
The five questions
You can ask all five in a management session without an engineer in the room. None of them need a technical answer. You're reading the room, not the reply.
The commit question. "Pull the last twelve months of commits on your most critical systems. Whose name is on the payments code, the reconciliation logic and the pipeline the board reports run on?" One name across all three, and you've found your key person before anyone's spoken.
The room question. Ask something specific and operational, "walk me through exactly what happens when a payment fails and has to be retried", then watch who everyone turns to. The person the room looks at is the answer, whether or not they're the one who talks.
The holiday question. "What happens to releases and deploys when that person is on holiday?" If the honest answer is "we wait until they're back", the platform has a single point of failure with a calendar.
The incident question. "Who was on call, or got phoned, for your last three production incidents?" The same name three times means your incident response is one person's mobile number.
The frightening-resignation question. "Whose single resignation would genuinely frighten you?" Ask the founder, then watch the pause before they answer. The hesitation is the finding. The name is just confirmation.
The sixth question is the paper one. The five above read the room, and a room can be coached for a management meeting. Paper can't. So before you leave, get four documents on the table. Proof the company actually owns its code repository, and that one exists at all rather than living in someone's personal GitHub. A signed IP assignment from the key person. A list of who holds the cloud accounts, the DNS and the secrets. And the on-call record for the last quarter. The worst version of this whole problem is the one where the commit question has no answer, because there was never a repository to look at.
One practical note on timing. Questions two, three and five work in a first management meeting, before you've spent a penny on the deal. One, four and six need data-room and code access, so they wait for exclusivity, and some sellers won't hand over code at all without a clean room. So the room questions are your pre-LOI screen, and the commit and paper questions are the confirmation you run once you're inside.
The most important engineer in the deal might not work there
By Juan Resendiz
Tom's five questions all point inward, at the people on the target's payroll. There is a sixth name worth chasing, and it is usually not in the data room at all.
In late March a self-hosted library app called BookLore vanished. Its sole maintainer, who went by the handle ACX, deleted the code repository, the Discord server and the project website overnight, with no notice. The project had more than 10,000 GitHub stars and thousands of daily users, according to XDA Developers, which reported the shutdown on March 31. Users found out when their updates started failing. A group of volunteers has since forked the code into a replacement called Grimmory, but rebuilding the infrastructure and the trust behind it will take months.
BookLore is a small project. The pattern under it is not. This is Tom's commit question asked one layer down, of the open-source code sitting inside almost every company you will ever buy. Whose name is on it? Often one person's.
The numbers do not comfort. Tidelift's 2024 maintainer survey, which polled more than 400 open-source maintainers, found 60 percent are unpaid and 60 percent have quit or considered quitting the work. Anchore's Josh Bressers, cited by the security firm Socket, counted 16 million of npm's 28 million package releases carrying a single maintainer. By one estimate drawn from Ecosyste.ms, roughly 10,000 people maintain the packages that account for 80 percent of all usage across the ecosystem. The 2024 XZ Utils backdoor, which came within a hair of reaching every Linux server running SSH, started with exactly this shape: one exhausted volunteer, quietly pressured into handing over the keys. CISA wrote up the lessons afterward. The shape did not change.
For a buyer the read-through is direct. The platform you are pricing rests on a stack of dependencies, and some of those dependencies are one burned-out person who owes you nothing and can walk at any hour. Tom's key-person risk does not stop at the edge of the building. It runs straight through the software bill of materials, into projects with no service-level agreement, no IP assignment you can enforce and no notice period to give. A signed inventory of what the code actually depends on, and which of those pieces sit on a single maintainer, belongs on the same table as the four documents Tom asks you to get before you leave.
None of this changes the deal you can do. It changes what you look at before you sign. The engineer answering Slack at 11pm is the risk you can see. The maintainer three imports deep, who has already thought about quitting, is the one you cannot, right up until the morning the repository is gone.
Disclosure: The Modernization Memo is self-funded and co-run by Juan Resendiz and Tom Barber, who operate a technical due-diligence practice. Neither holds a position in any company or project named above.
The 90-day plan that defuses it
Here's the plan I run after close. Composite, several businesses, and the tell never varies: a payments platform, one engineer who hadn't had an uninterrupted week off in years, and a ninety-day programme whose real deliverable turned out to be his holiday rather than any document.
The goal is narrow and measurable. At the end of ninety days the key person can take a real two-week holiday, phone off, and nothing breaks and nobody texts them. That is the acceptance test. Everything below serves it.
First, be honest about which situation you're actually in, because the plan assumes something most companies with this problem don't have: someone to transfer the knowledge to. The absence of that someone is usually why the risk exists.
You have internal capacity. Then it's ninety days, as below.
You have to hire the Successor. Then weeks one to six are a recruitment, and this is a 150-day plan with a search cost attached. Worse, hiring opens the most dangerous window in the whole story: the Owner can resign in week two of your search and take everything with them. Start the transfer with whoever you already have while you hire, even if they can only hold half of it, and treat that window as the risk you're most exposed to.
You pull someone off revenue work. Then there's a real opportunity cost. It belongs in the plan, not hidden underneath it.
The cast. The Owner is the key person. The Successor is whoever holds the knowledge afterwards, and if you can possibly name two, name two, because moving everything into one new head just relocates the bus target. The Sponsor is the one the org chart discussion always forgets: someone with real authority, the operating partner or an exec the board has told to make this happen. The Sponsor enforces the behaviour the plan depends on, because the Owner's whole leverage is being indispensable, and not everyone gives that up willingly. Their incentive to let go is the retention you'll read about below. That's the join between the two halves of this issue.
Week 1, inventory. The Owner lists every system, pipeline, tool and account they alone hold. The Successors get full access to all of it. Nothing is documented yet. The deliverable is the list, and it's always longer than anyone expected.
Week 2, the stuck list. Each Successor attempts the real tasks cold while the Owner watches in silence and does not rescue them. This is the load-bearing week, and it only works if the Sponsor holds the Owner to it. Log every point they get stuck. Rank the list by how often the task runs multiplied by how badly it hurts when it breaks. That ranking is your documentation order. You write up the top of it first, not the bit that's easiest to write.
One outcome of this week is worth calling out. Sometimes nobody else can run the system because the system isn't maintainable, not because the knowledge is hoarded. If week two tells you that, stop. This isn't a transfer, it's a rebuild, and you price it as one. Handing an unmaintainable system to a new person just resets the clock on the same risk.
Weeks 3–4, the critical path. Top of the stuck list, usually the release process and the payments or reconciliation code. The Successor drives real deploys and real fixes, and the Owner sits behind. The Successor writes the runbook as they go, because a runbook written by the Owner skips the ten things they do without thinking, and one written by the learner captures exactly those ten.
Weeks 5–6, the data pipelines. Same pairing, Successor driving. The runbook covers how it's scheduled, how you know a run has failed, and how to rerun or backfill without making it worse.
Weeks 7–8, infrastructure, tooling and internal apps. The Successor makes a real change to each with the Owner behind them. Capture the "where everything lives" map: accounts, DNS, secrets, deploy keys, where the servers actually are. This is the material that exists nowhere but one person's memory.
Weeks 9–10, structure the redundancy. Every critical system gets a named owner and a named backup, written down. On-call gets a second name. The Successor takes primary on-call for a fortnight with the Owner as backup, not the other way round.
Weeks 11–12, the real test. The Owner takes an actual booked two-week holiday, phone off. Not a fire drill. Anything that breaks, or triggers a "quick question" text, is knowledge that hasn't transferred. The Successors handle it and log every gap. This fortnight is worth more than the six weeks before it.
Week 13 (day 90), close and sign off. Close the gaps the test exposed. The sign-off condition is simple: every critical system has a documented owner and a backup who has done the job unaided, and the Owner is off the critical path. Not eased out. Freed to do the work only they can do, which was why you were glad to have them.
Done properly you don't lose the key person. You lose the risk they represented, and you keep the person.
The money conversation is for subscribers
Spotting it and defusing it are above, free. The half that decides whether you overpay is what you do in the deal: what comes off price versus the multiple, why the indemnity escrow is the wrong instrument for this and what to use instead, how retention splits between an employee and a founder-seller, and the two findings most buyers walk past. That goes to subscribers.