The questions that separate a real technical diligence from a checklist. Use them on the next platform you are considering, or on your own.
We run technical diligence for sponsors who don't want a 90-page report. They want to know if the platform they are about to underwrite can survive the next three years of pressure. Most of the standard diligence questions, the ones that come in the checklist with the template, don't get at that. The questions that do tend to be specific, sometimes awkward, and easier to ask than to answer.
What follows is the short list we keep coming back to. Use it on the next platform you're considering, or on your own team. It works in either direction.
The ten
- When did the team last successfully restore from a backup, and who watched it happen?
- What percentage of revenue depends on code that no current employee wrote?
- If your most senior engineer left tomorrow, name three systems that go dark in the first quarter.
- What is the largest customer's escape clause in the contract, and how plausibly could they trigger it?
- Show us the last three on-call rotations and the postmortems. The unpolished ones, not the ones kept for board decks.
- What is the slowest decision-making body in the company, and what is the average time to get an answer from it?
- Which engineer says "no" most often, and is that person still here?
- How many production systems have a single point of failure that is a vendor relationship?
- Where does customer data live outside the canonical store? Spreadsheets count.
- What is the team going to be doing in 2028 that they can't do today, and what specifically has to be true for that?
How to use them
The list isn't a checklist. We use it as the spine of a conversation. The first answer is rarely the interesting one. The interesting answer is what the room says after the question lands and there is a short silence. The diligence is in the silence.
If a team can answer all ten without pause, they are either remarkable or rehearsed. Either way, ask one more.