# Before You Buy It — a product & technology diligence checklist

Seven stages. Two columns each: what to request, and what to ask.

The request column is the part every checklist has. The ask column is the
part that predicts what owning this will be like, and it is the first thing
cut when the timeline compresses.

Source: https://thinkkeno.com/technical-due-diligence-checklist/

---

## 1. Customer — will they stay?

**Request:** revenue by account, renewal dates, churn history, support volume
by customer, contract terms and any non-standard ones.

**Ask:**
- [ ] Who inside the customer actually championed this purchase, and are they still there?
- [ ] Which accounts renewed because of a person rather than the product?
- [ ] What happens to the top three accounts if the founder stops taking their calls?
- [ ] Which customers are on non-standard terms, and who agreed to them?
- [ ] What has been promised verbally that is not in a contract?

## 2. Product — what has been promised, to whom?

**Request:** roadmap, feature inventory, open issues, recent releases.

**Ask:**
- [ ] What is on the roadmap because a customer was promised it?
- [ ] What does the team believe the roadmap is, asked separately from leadership?
- [ ] Which features are load-bearing for revenue but unloved by the team?
- [ ] What would you cut tomorrow if nobody would be upset?
- [ ] What is the last thing that shipped late, and why?

## 3. Technology — what will this cost to run and to change?

**Request:** architecture diagram, infrastructure spend, dependency list,
security posture, incident history.

**Ask:**
- [ ] Show me the commit history for the last six months, not the diagram.
- [ ] What is the on-call rotation, and how often does it fire?
- [ ] What would you fix first if you had a free month?
- [ ] Which part of this system does exactly one person understand?
- [ ] What is the oldest dependency, and what breaks if it stops being maintained?
- [ ] How long does it take to get a one-line change into production?

## 4. Team — who understands this, and what happens at close?

**Request:** org chart, comp bands, tenure, retention terms being offered.

**Ask:**
- [ ] Who would you not want to lose, in order?
- [ ] What changes for an engineer here the day this closes?
- [ ] Who is staying for the money, and what is their date?
- [ ] Who has been here longest, and what do they know that is not written down?
- [ ] If the founder left in six months, what stops working?

## 5. Economics — which costs are structural?

**Request:** P&L, unit economics, cost of goods, headcount plan.

**Ask:**
- [ ] Which work is currently being done by a founder for free?
- [ ] What does this model look like once that work has to be hired?
- [ ] Which costs scale with customers and which scale with usage?
- [ ] What is deferred — maintenance, upgrades, hiring — and for how long?

## 6. Risk — what is load-bearing that nobody wrote down?

**Request:** compliance status, audit history, open legal matters, key contracts.

**Ask:**
- [ ] What are you most worried about that has not come up in this process?
- [ ] What would be embarrassing if it surfaced after close?
- [ ] Which single vendor, person, or contract could stop this business?
- [ ] What has almost gone badly wrong in the last year?

## 7. Integration — consolidate or leave alone?

**Request:** current tooling, deployment process, release cadence.

**Ask — of your own side, before close:**
- [ ] Name the mechanism by which this product got good, in one sentence.
- [ ] Which consolidations threaten that mechanism?
- [ ] What are we consolidating because it is genuinely undifferentiated?
- [ ] What are we consolidating because it is tidy?
- [ ] What is our baseline for decision latency, measured from day one?

---

## The two rules

**Reserve time for unstructured conversation with the people who will still be
doing the work after close.** Not a presentation. Without their leadership in
the room. It is the cheapest instrument here and the first thing cut.

**Write down what you decided to leave alone, and why.** A playbook without
stated reasons is a list, and lists get executed by people who were not in the
room when the judgment was made.