Technical Due Diligence 2026: What One Person Costs You

Technical due diligence in 2026 puts a price on key-person concentration. When a buyer, lender, or auditor asks who else can modify your system and the honest answer is nobody, that answer becomes a number in their model, typically a 5% to 25% reduction, before anyone discusses a single feature or customer contract.

Deals get repriced on that basis every quarter, and most mid-market CEOs only learn the question is coming when someone asks it across a conference table. The artifacts that prevent the discount (architecture documentation, decision records, API references, test coverage reports) are the specific items a reviewer works through, in order, before writing the finding that changes your number.

Quick answer: technical due diligence now prices key-person risk

1. A reviewer who finds one person holding all system knowledge prices it, often a 5% to 25% valuation discount.
2. Reviewers want six artifacts: architecture documentation, decision records, API references, test coverage reports, user story libraries, and more than one person with commit history.
3. The finding surfaces as a lower multiple, an earnout, a longer seller transition, or an escrow holdback, sometimes several at once.
4. Key man insurance pays out after the person leaves. The documentation still has to exist.
5. With no exit planned, those artifacts are what let anyone else touch your system.

A technical diligence reviewer checks architecture documentation and commit history before writing a finding.

Technical Due Diligence 2026: The Question That Prices Your Company

A technical diligence reviewer sitting across from your CFO asks one question: who else on the team can modify this system? If the honest answer is nobody, that sentence has just turned into a financial variable.

Where the question gets asked: an acquisition, a credit facility, an insurance renewal, an audit

This question surfaces in more rooms than most CEOs expect. An acquirer’s technical diligence team raises it in the data room, often three weeks before close. A lender’s credit committee wants an answer before extending a facility secured against the business, because the collateral has to keep functioning if key staff leave. Insurers ask during a cyber or operational-risk renewal, since concentrated knowledge is itself a loss exposure. And an auditor works through it as part of IT general controls testing, where segregation of duties counts as a control objective.

Each of these rooms runs the same test: can more than one person change this system safely? If the answer is one person, or a contractor who hasn’t touched the codebase in eighteen months, the finding goes in the report.

SRS Acquiom’s 2026 M&A due diligence study found that 47% of practitioners now call technical diligence their top priority of the past year, and 51% call it the single most burdensome part of the entire review. Software quality and continuity used to sit behind financials and legal as a secondary workstream. That ordering is gone.

Why “only Marcos knows that one” is a financial answer, not a technical one

Say the name out loud in your head. Every mid-market company has one: the engineer or contractor who built the order-routing module or the billing reconciliation job and never wrote down why.

When a reviewer hears “only Marcos knows that one,” what registers is a probability, not a staffing gap: the chance Marcos leaves, gets sick, or asks for a raise the acquirer isn’t planning to pay, multiplied by the cost of the business not functioning while someone else works out what he knew. Probabilities get priced.

What Key-Person Concentration Costs in Real Deal Terms

Business valuation practitioners work with a range of five to twenty-five percent when a closely held company depends on one irreplaceable person. It gets applied before anyone touches your revenue multiple for anything else.

Call it the key person discount. Nobody is penalizing you for having talented people. The buyer is pricing in the chance that the system’s actual operator leaves within the hold period and nobody else can keep it running at the same level.

Lower multiples, earnouts, escrow and a seller transition period that keeps you in the building

The discount rarely shows up as a single line item labeled “key person risk.” It gets distributed across deal mechanics instead. A lower headline multiple. An earnout tying a chunk of your payout to performance over the next 18 to 36 months, so the buyer isn’t fully exposed if the system falls over once you’re gone. An escrow holdback, funded out of your own purchase price and released only after the transition period proves the system survives without you. A seller transition clause that keeps you, or your key engineer, contractually obligated to the business for months past close.

A synthesis of 30 employee-turnover case studies puts the typical cost of replacing someone at about 21% of annual salary, rising as high as 213% for senior and very highly paid roles. On top of that the seat usually sits unfilled or underperforming for six to twelve months. A buyer who has already run that math doesn’t need the risk explained. The ask is that you absorb part of it.

When the finding reprices the deal and when it ends it

Most of the time this is a repricing event rather than a deal killer. The buyer still wants the business. They just want a lower price, a longer earnout, or more of your time locked in before they’ll sign at the number you wanted.

The deal ends only when the concentration is total: one person holds knowledge the business can’t function without, that person has no intention of staying, no documentation exists to replace them, and the buyer concludes the operational risk outweighs the opportunity. That combination is rare, and it is also the version every CEO assumes applies to them, which is backwards. The common outcome is a worse price, and a worse price is something you can still prevent.

Concentrated commit history is one of the first things a diligence reviewer checks.

How a Diligence Reviewer Actually Finds It

You can’t talk your way past a commit log. A reviewer pulls the evidence rather than taking your word for how distributed the engineering knowledge is, and the picture is usually unambiguous by the end of the first afternoon.

Commit history and code review distribution across the team

Commit history comes first, and the reviewer is reading it for concentration rather than line counts. How many distinct people have touched the core modules in the last 12 to 24 months? How many pull requests get reviewed by someone other than the person who wrote them?

An academic study of 133 widely used software projects found that 65% had a truck factor, more commonly called a bus factor, of two or lower, meaning two departures or fewer would stall the project. Mid-market internal systems, built by smaller teams with less review discipline than open-source projects, tend to run worse than that.

If you want the longer version of what that number means and why it concentrates specifically in mid-market software, bus factor of one walks through it in more depth. Here it is one input among several that the reviewer folds into a single judgment.

Who holds infrastructure, deployment and production access

Commit history tells half the story. Access tells the rest. Who has the production database credentials? Who can deploy to the live environment? Who holds the cloud console root account?

In a surprising number of mid-market systems, the answer to all three questions is the same one or two names, and at least one of those names belongs to someone who left the company, or the vendor’s team, months ago and was never offboarded. A reviewer checking access control is testing something narrow: whether the business can survive an incident without calling someone who no longer works there.

The interview round, where one name keeps coming up

Eventually the reviewer talks to your team. Who do you go to when something breaks in this module? Who wrote this? Who would you call if this failed at 2 a.m.?

The same SRS Acquiom study found that 73% of M&A practitioners expect diligence to grow more complex over the next one to two years, and 57% say the process has already added one to three months to deal timelines. Interviews are a big part of why. When the answer to every question is one name, the reviewer stops asking new questions and starts writing the finding.

The Artifacts a Reviewer Asks For, and What Each One Is Worth

Six items show up on almost every technical diligence checklist, and each one exists to prove the same thing: system knowledge doesn’t live in one head. The sections below cover what gets checked and what skipping each one costs you in the report.

Architecture documentation and system design docs

A reviewer wants a map before they trust anyone’s verbal description of the territory. UML diagrams and system design documents show how services, databases, and integrations connect without requiring an hour of someone’s time to explain it out loud. Without them, the reviewer’s understanding of your system depends entirely on whoever is in the room that day.

Architecture decision records: why the system is the way it is

Diagrams show what the system is. Decision records show why it’s that way, and why a seemingly odd choice was deliberate rather than an accident waiting to be “fixed” by a new team. Missing decision records mean every future engineer re-litigates choices someone already made, usually for reasons that made sense at the time and still do.

API references that a second team can build against

Swagger or Postman references let a new engineering team, yours or an acquirer’s, integrate with your system without reverse-engineering the API by trial and error. A reviewer treats a missing API reference as a signal that integration work after close will cost far more than anyone budgeted.

Test coverage reports as evidence a change can be made safely

Coverage reports answer a specific question: can someone change this code without breaking it silently? Low or absent coverage means every future change is a gamble, which is precisely the risk profile a reviewer is paid to flag.

Requirements and user story libraries

A library of user stories and requirements tells a reviewer what the system is supposed to do, independent of what the current code happens to do today. That gap, between intent and implementation, is where a lot of hidden technical debt actually lives.

More than one person with commit history

This is the summary artifact the other five support. The real question behind all those document requests is whether a second, third, and fourth person could step in tomorrow and keep shipping. Documents without distributed commit history are a partial answer, and distributed commit history without documents is fragile. A reviewer wants both.

Every Nexa engagement ships these items, UML architecture diagrams, system design documentation, user story libraries, Swagger or Postman API references, and test coverage reports, as standard deliverables, owned by the client the moment they are produced, whether the engagement runs another month or another decade. The list is the same one a diligence reviewer works through, built in from day one instead of reconstructed under deal-timeline pressure.

what a bus factor of one actually looks like inside a real mid-market system

Architecture diagrams, decision records, API references, test coverage, requirements, and distributed commit history: the six artifacts a reviewer checks.

Documentation Red Flags That Get Scored Against You

Monday, 7:15 a.m. A routine update throws an error. Order creation stops. The dashboards operations relies on go dark. The only person who understands how that system is configured hasn’t worked there in two years.

Being disorganized with documentation, or repeatedly failing to produce basic information

The reviewer asks for architecture docs, then the deployment runbook, then the test coverage report. If the honest answer three times running is “let me check” followed by silence, the reviewer stops reading it as disorganization and starts reading it as absence. Either way it lands in the report.

A bus factor of exactly one, and the contractor-drifted-away case of zero

Most under-documented mid-market systems sit at a bus factor of exactly one: one person who could, in principle, explain and modify the whole thing. The more dangerous variant is a bus factor of zero. The original contractor moved on, nobody internal was ever truly handed the keys, and the system runs on inertia. That version skips the lower price and goes straight to the hardest conversation in the entire diligence process.

The outage that teaches you the number: one failed update, orders stop, production halts

Every company with a bus factor problem eventually gets a free lesson in what that number means, usually at the worst possible time. The failed Monday update is the generic version of the story. The specific version, in your company, already has a name, a system, and a person attached to it. The only open question is whether you learn the lesson before a reviewer writes it down for you, or after.

Why Mid-Market Systems Nobody Built to Sell End Up Here

Nobody sat down and decided to concentrate years of system knowledge in one person. The system you’re running today is the sum of a dozen reasonable, deadline-driven decisions, none of which treated handover as a requirement.

You hired the contractor who could start Monday, not the one with the best documentation habits, because the order system needed to ship before the holiday season. The architecture diagram got skipped because the team was three people and everyone already knew how it worked. The original engineer’s handoff notes ended up on a shared drive nobody ever indexed, since reorganizing a wiki wasn’t anyone’s job description. Every one of those was a reasonable call in isolation, and nothing in the engagement, the contract, or the vendor relationship ever required otherwise. Documentation was never a condition of delivery.

The root cause is duller than it sounds: the system was built to work, not to be handed over. Working software and transferable software are different deliverables, and most mid-market engagements only ever specified the first. Fix the specification and the gap closes. Keep specifying “ship it” without also specifying “document it, and prove someone else can run it,” and you will rebuild the same gap with your next vendor.

As Kamila Hankiewicz, Founder and CEO, writes in her analysis of risk management and the bus factor: “Your mission as a founder should be to make yourself replaceable: company progress should not depend on you being present.” The same standard applies to anyone on the team, not only the founder. A system that depends on one irreplaceable person says less about the quality of that person’s work than about whose job it was to make them replaceable. Usually nobody’s.

Making the Artifacts a Condition of the Work, Not a Cleanup Project

Fixing this is a procurement decision, not an engineering sprint you have to supervise personally. You specify documentation transfer as a contract condition, the same way you’d specify a deadline or a payment milestone.

What “client-owned and transferred regardless of engagement status” means in practice

The phrase matters because of what it rules out. Documentation that lives in a vendor’s internal wiki and disappears when the contract ends. Architecture diagrams that exist only in one engineer’s head, portable for exactly as long as that engineer stays reachable. API references written eventually, after the deal, after someone finally asks for them under pressure.

On a Nexa engagement, the UML architecture diagrams, system design documentation, user story libraries, Swagger or Postman API references, and test coverage reports are delivery line items rather than favors, and the client owns them the moment they are produced, independent of whether the engagement continues.

What it costs to reconstruct the same artifacts after the fact, under deal timeline pressure

Reconstructing documentation after the fact is always more expensive than building it alongside the code, and it gets dramatically more expensive once a deal clock is running. A reviewer working to a 60-day close doesn’t wait patiently while your team reverse-engineers eighteen months of undocumented decisions.

You pay for rushed, incomplete reconstruction, or you accept the discount, or both. Building the artifacts as a condition of the original engagement is cheaper by a wide margin, because nobody is paying a deal-timeline premium for work that should have happened the first time.

Schedule a call if you want a plain-language read on where your own systems stand against this checklist before anyone else asks the question.

Documentation transfer specified as a contract condition, not a post-project favor.

If You Are Not Selling, This Is Still the Only Reason It Matters

Most companies reading this have no acquisition, credit facility, or audit scheduled. So why does any of it matter if nobody is checking?

Because the risk a reviewer uncovers is not a special category that shows up only when someone wants to buy you: it is the same risk that stops your own team from touching the system next Tuesday. The architecture diagrams a reviewer asks for are the diagrams your new hire needs to make a first change without breaking production. The decision records are what keep your team from re-litigating a choice someone already made and documented three years ago.

Gartner’s research puts a number on the adjacent problem: 60% of AI projects will be abandoned by the end of 2026 because the underlying data and documentation aren’t ready to support them. Diligence is only the first thing an undocumented system fails. It also fails every future initiative that depends on someone other than the original builder understanding what is there, AI integration work included.

Modernizing a system incrementally, without betting the business on one risky cutover, depends on the same foundation: documentation good enough that more than one person can touch the system safely. Build it because a deal might happen one day. Build it mostly because, until it exists, almost nothing else you want from this system, the AI work included, is within reach.

A second engineer working from documented architecture, the same artifact a diligence reviewer and a new hire both depend on.

 FAQ