Docs Questions to ask the CTO
Guide

Questions to ask the CTO in technical due diligence

A meeting with the target's CTO is usually an hour, and it goes further when the buyer has read the code first. This guide lists the questions a buyer asks, grouped by area. For each one it says what the repository can show before the meeting, and what only the CTO can answer. Check the first part in advance, and spend the hour on the second.

How to use the hour

  • Read the repository first. An answer you have already checked becomes a confirmation, not a discovery. The technical due diligence checklist has a command for each check.
  • Ask about what you found. "Who reviews changes to the billing code?" gets a better answer than "How do you do code review?"
  • Ask for the document behind the answer. An incident log, an architecture note or an on-call rota is evidence. A recollection is a starting point.
  • Write down what was promised. Answers about plans and people often become warranties, conditions or retention terms in the deal.

1. Architecture and ownership

  • What are the main parts, and who knows each? The repository shows how the code is divided, which parts are largest, which change most, and who has changed each part recently. Only the CTO can say which parts are hard to change, and why.
  • What would you rebuild with hindsight? The repository shows old frameworks, runtimes past end of life, and very large files that change every week. Only the CTO can say what a rebuild would cost, and whether it is planned.
  • Is everything that runs the product in the code you've given us? The repository shows submodules and references to other repositories. Only the CTO can say which repositories, scripts and configuration were left out of the data room.

2. Key people

  • If your two most active engineers left next month, what would stop? The repository shows how much of the recent work came from one person, and which parts only one person has touched. 
    git shortlog -sn --no-merges --since="24 months ago" | head
    Only the CTO can say whether those people are staying, and on what terms.
  • How does a new engineer learn the system? The repository shows whether there is a README that sets the project up, architecture notes, and comments where the code is unusual. Only the CTO can say how long onboarding takes in practice.
  • Who outside the team has written code here? The repository shows how many authors there are and when each was active. Only the CTO can say which were contractors, and whether their contracts assign the copyright.

A single contributor carrying the work is common. In 668 of the 1,656 public projects in Borehole's library, one contributor wrote more than half of the last two years' commits, and the median one of those had 24 people commit in the same period. The key-person report counts it across the library.

3. Security history

  • Has a secret ever been committed, and was it rotated? The repository shows credentials in the history, including ones deleted since. Only the CTO can say whether each was rotated, and when.
  • What were your last two security incidents? The repository shows dependency versions with published advisories, and fixes that look like responses to incidents. Only the CTO can say what happened, who was told, and what changed after. Ask for the postmortems.
  • Who outside the company can reach production, the code or customer data? The repository shows very little of this. Ask for the access list and the last penetration test.

4. Licences

  • Has the product's licence ever changed? The repository shows every change to the licence file, with its date. Only the CTO can say why, and what customers were told.
  • Do you use anything under AGPL, BUSL or SSPL, and how? The repository shows committed third-party code and its licence files. Only the CTO can say how each component is combined with the product, which decides what the licence asks. AGPL, BUSL and SSPL in a software acquisition explains each.
  • Who owns the code outside contributors wrote? The repository shows whether there is a contributor licence agreement. Only the CTO can say whether every contributor signed it.

Licences change more than buyers expect. Of the 1,656 projects in Borehole's library, 398 changed their licence in a way that changes what users may do. Every change is listed with its date.

5. Dependencies

  • How far behind are your dependencies, and why? The repository shows the lock files, the versions pinned, and known advisories against them. Only the CTO can say which upgrades were held back on purpose.
  • Which outside services would hurt most if they changed their price or shut down? The repository shows the SDKs and endpoints the code calls. Only the CTO can say what each contract costs, and whether it can be assigned to a buyer.

6. Release process

  • How does a change reach production, and how often? The repository shows the CI configuration, whether tests run on every change, the release tags and how often they come. 
    git tag --sort=-creatordate --format='%(creatordate:short) %(refname:short)' | head
    Only the CTO can say what happens between a tag and production.
  • Is what's on the main branch what customers run? The repository shows whether the newest release is on the main branch, or on a branch of its own. Only the CTO can say which versions customers are on.
  • Who can merge without a review? The repository shows how many changes landed without a merge or a second author. Only the CTO can say what the branch protection rules are.

7. AI-written code

  • How does the team use AI coding agents? The repository shows commits that declare an AI agent as co-author, and any policy in the contributing guide or agent instructions. Only the CTO can say how much code was written that way without saying so. A declaration is a line a contributor chose to keep.
  • Who reviews what an agent writes? The repository shows whether those changes passed through review like the rest. Only the CTO can say what the review checks.

Declared AI co-authorship is now usual. In 2026, 1,133 of 1,443 projects in Borehole's library with enough commits to say had at least one commit that declares an AI agent as co-author. The AI co-author report counts it year by year.

8. Infrastructure and cost

  • What does hosting cost, and how does it grow with customers? The repository shows the infrastructure code, if there is any, and the services it creates. Only the CTO can say what the bills are. Ask for twelve months of them.
  • What pages someone at night? The repository shows alert rules and monitoring configuration. Only the CTO can say who is on call, how often they are woken, and for what.
  • Could you rebuild production from the repository? The repository shows whether infrastructure is written as code or set up by hand. Only the CTO can say when a restore from backup was last tested.

Reading the repository before the meeting

Borehole reads the repository part of these questions. 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 arrive with the questions above already narrowed to this company.

  • A public repository. Paste its address. The survey is free.
  • A private repository. The collector reads it on the target's machine, and the 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. Surveying a target says how a buyer asks the target to run it.

The questions on one page

  • Which parts are hard to change, and what would you rebuild?
  • Is every repository that runs the product in the data room?
  • If your two most active engineers left, what would stop?
  • Which contributors were contractors, and who owns their code?
  • Was every committed secret rotated? What were the last two incidents?
  • Has the licence changed? How is any AGPL, BUSL or SSPL code combined with the product?
  • Which upgrades were held back, and which outside services matter most?
  • How does a change reach production, and is main what customers run?
  • How is AI used, and who reviews what it writes?
  • What does hosting cost, who is on call, and when was a restore last tested?

The technical due diligence checklist covers how to check each answer, and preparing for due diligence is the CTO's side of the same meeting.