Docs Preparing for due diligence
Guide

How to prepare for technical due diligence

A buyer's engineers will read your repositories, your history and your process, and every surprise they find becomes a price cut, an escrow or a condition. This guide is for the founder or CTO of a software company that expects to sell or raise in the next six months. It says what to look at first, what to fix, what to write down, and what to leave alone.

Start three to six months before

Most of what a buyer weighs is in the history, and the history cannot be improved quickly. What you can do in a few months is find the problems first, fix the cheap ones, and prepare a plain answer for the rest. A known problem with a plan costs less in a negotiation than the same problem found by the other side.

1. Read your own code the way a buyer will

  • Run the buyer's checklist on yourself. The technical due diligence checklist lists what a buyer's engineer checks and the command for each. Run it on every repository the product needs, including the ones nobody has opened in a year.
  • List every repository. A buyer asks for all of them: the product, the infrastructure, the mobile apps, the scripts. A repository you forgot to mention reads as one you hid.
  • Write down each finding as a question. For each, record the evidence (the commit, the path, the line), what it costs to fix, and whether you will fix it before the deal or explain it.

2. Fix what is cheap and visible

  • Secrets in the history. A credential committed once stays in every clone, even after the file is deleted. Rotate it now, at the service that issued it. Rotation is the fix; rewriting the history to hide it is not. 
    git log -p -S 'BEGIN RSA PRIVATE KEY' --all | head
git log -p -G '(api|secret)_?key\s*[:=]' --all | head
  • Known vulnerabilities in dependencies. Upgrade what has a fix. For what you cannot upgrade yet, write one line on why it does not reach production, or when it will be fixed. 
    npm audit --omit=dev        # or: pip-audit, govulncheck ./..., cargo audit
  • A missing or unclear licence. Every repository needs a licence file that matches what you intend. A private product should say it is proprietary. Copied-in code keeps its own licence: list it.
  • Tests that CI does not run. A suite that exists but does not gate merges proves little. Make CI run it, and fix or delete the tests that have been failing for months.
  • Pinned versions. Commit the lockfiles. A build that resolves different versions each time cannot be reproduced by the buyer's team.

3. Spread the knowledge

The question a buyer asks most often about a small team is what happens if one person leaves. They will read it in the history: who writes the code, who reviews it, and whether one account merges almost everything.

  • Review each other's changes. From now on, every change to the main branch goes through a pull request that someone else approves. Six months of that shows in the history.
  • Pair on the parts one person owns. Billing, deployment and the oldest module are where knowledge usually sits with one person. Have a second engineer make a real change in each.
  • Prepare the answer you cannot change in time. If one person wrote most of the product, say so, and say what keeps them: their role after the deal, the documentation, the handover plan.

4. Write down what only your team knows

  • An architecture overview. One page: the services, where each runs, what data each holds, and how they talk to each other.
  • How to build, deploy and roll back. A new engineer should be able to ship a change from the documentation alone.
  • Operations. What is monitored, who is paged, the last three incidents and what changed after each.
  • Third parties. Every service the product depends on, what it costs, and what data it receives.

5. Say how you use AI

Buyers now ask who wrote the code and with what tools. The question is not whether AI was used. It is whether you know where, and whether the terms allow what you shipped.

  • Write a policy. One paragraph in your contributing guide: which tools are allowed, and that a person reviews what they produce. How open-source projects word theirs counts where projects put it and how many do.
  • Keep the declarations. When a commit names an AI agent as co-author, keep that line. Squashing or rebasing it away does not remove the AI's part; it removes the evidence that you knew.

6. What never to do

  • Rewrite the history. A force-pushed main branch, squashed years or a fresh repository with one initial commit is the first thing a buyer's engineer notices. It reads as concealment, and the original is usually still on someone's laptop.
  • Delete tests or checks to make CI green. The deletion is in the history with a date.
  • Change the licence in the last month. Code released under the old terms stays under them. A late change raises the question and answers nothing.

7. Prepare the data room

  • Read access to every repository, or a plan for how the buyer will read the private ones without taking a copy.
  • The architecture overview, the runbook and the list of third parties.
  • Your own findings, with what you fixed and what you plan to.
  • Security reports and penetration tests, with what was fixed after each.

Reading your own repositories first

Borehole reads a repository the way a buyer's engineer does. It reads the git history and working tree, runs 106 diligence checks, and rates it on 7 dimensions:

  • Architecture & Codebase — including AI provenance
  • Engineering Process & SDLC Maturity
  • Organization & Key-Person Risk
  • Product & Engineering Maturity
  • Security & Reliability Posture
  • Observability & Operations
  • Fit with the Acquirer

Every finding cites its evidence, and what the code cannot answer becomes a question for the room, so you see the questions before the buyer asks them.

  • A public repository. Paste its address. The survey is free.
  • A private repository. The collector reads it on your machine, and your repository stays there. What it sends: never whole files; facts and short excerpts of up to 120 characters where a check matched. The dry run prints everything a survey would send, and sends nothing. 
    pip install borehole
borehole collect . --dry-run   # prints everything that would be sent, sends nothing
borehole collect .             # sends it, returns a report
    A survey of a private repository spends a Report key. A Borehole Report costs €249 launch price · €499 after launch. What happens to your code lists everything the collector sends.

The preparation on one page

  • Run the buyer's checklist on every repository; list them all
  • Rotate every secret the history holds
  • Upgrade dependencies with known fixes; explain the rest
  • A licence file in every repository; list copied-in code
  • CI runs the tests and gates merges
  • Every change reviewed by a second person from now on
  • A second engineer works in each single-owner area
  • Architecture, deployment, operations and third parties written down
  • An AI policy in the contributing guide; declarations kept
  • Never rewrite the history or change the licence late