Technical due diligence: read the bill before the code

A technical due diligence answers one question before you buy or fund a product: what exactly are you taking on? The demo shows what the product does. It doesn't show what the system costs to run, which parts would have to be rewritten, or what breaks if the two people who know it leave.

I haven't done one under that name for an acquisition. The way I would do it comes from systems I joined and had to understand quickly, where nobody could tell me everything the code did. In each of them, the first useful document was the bill.

On a national identity system in West Africa, the AWS bill came to $24,000 a month. The workload needed about an eighth of that, and nothing had raised an error. Six months later the same system ran for $2,000 a month, with the same users doing the same work and nothing decommissioned.

The excess had three causes, and each was found a different way:

• Sizing. Everything was over-provisioned, which shows up when you compare provisioned capacity with observed use.
• A fault. Infinite loops were consuming compute around the clock. They show up as cost that doesn't follow traffic: high utilization that no user action explains.
• The architecture. Uploads went through the backend on their way to S3. That one only shows up in the code.

For a buyer, the split matters more than the total. Sizing is a configuration change. A fault is a bug fix. An architectural cause is a rewrite of a path through the system, with a price and a schedule of its own. A bill that is too high tells you very little until you know which of the three you are paying for.

The bill also comes first because it is the one record nobody wrote to describe the system. It records what ran, every hour, whatever the team believes the system does.

Typecheck, lint and a green build say little about whether a system does what its authors think it does. They also produce long lists, and a list of two hundred findings doesn't tell you what fixing them costs.

One cause often sits behind many of them. When uploads go through the backend, every photograph occupies server memory for the length of the request, requests take longer, and the servers need more capacity than the traffic suggests. That reads as three problems, and it is one decision about where the file goes. The assessment should name that decision and put the hundred symptoms under it.

On the data warehouse of a supplier to large US retail chains, neither the queries nor the schema could change. A BI tool generated the queries, and customers had saved reports built on the schema. The largest customer's report took over fifteen minutes. It now opens in 0.2 seconds, and no customer had to rebuild a saved report, because the work went into the system the queries ran against.

A new owner runs into the same kind of limit. Saved customer reports, apps already installed on phones and third-party systems that call your API all hold interfaces in place. Those limits decide what can be changed, and so what it costs, more than anyone's preferences do. An assessment that recommends a rewrite without listing them is guessing at the price.

The costly problems look like normal operation: an infinite loop, uploads routed through the backend, a code comment that still describes an earlier version of the function below it. Monitoring catches errors, and none of these is an error. They are found by looking on purpose, which is most of what the assessment is for.

• What the system costs to run, broken down by billing line, and how much of that comes from sizing, from faults and from the architecture.
• Where the risks are: data access, secrets, authentication and anything else that would fail a security review.
• A part-by-part view of what can stay and what would have to be rewritten, with the reasoning written out.
• What was not checked, written down, so the document isn't read as more than it is.

A sound codebase still gets the full document: why it is sound, what it costs to run and the list of what wasn't checked. That is worth having in writing before you sign.

Read access to the code repositories and to the billing data. Production data isn't needed. Whether the team knows about the assessment is your decision, though it goes faster if some of their time is available to confirm what the code can't tell. The delivery date is agreed before the work starts, and an NDA is signed if you want one.

If you have only an afternoon, start with the bill. Break it down by billing line and ask, for each line, which user action pays for it. Any line nobody can answer for is where to start reading the code.