The technical due diligence checklist we actually run

A technical due diligence is twelve questions. Five of them come out of the repository in a day of measurement. The other seven you can only get by asking, and they are the ones that move the price. Almost everything written about this subject stops at the first five, because that is the part a tool can sell.

We ran the whole list on a platform in food and health that we had already woken from a 928-day silence and assessed two years late. Three repositories: a web admin, a backend and a mobile app. This time the question was not whether to save it but what a buyer would have needed to know, and we ran it the way we would for a buyer: fresh clone, no memory of the code allowed to count.

Five questions the repository answers

1. Who wrote it, and are they still around?

Two people wrote half the surviving code in all three repositories — the top author is at 35–41% in each. Of those two, one is still active on the admin and the app, both on the backend. And 20–52% of the surviving lines were last touched by somebody who never came back.

That is the number to put next to the purchase price. A buyer inherits the code, not the people, and here the code has a second author who has already left.

2. How alive is it?

Last commit dates, commit cadence, and the longest silence. The longest here was 928 days, which is the whole story of the first article. A codebase does not rot while nobody touches it; the ground under it does, and the length of the silence is how much ground has moved.

3. What is it standing on?

40% of the backend's dependencies were stale, and its entire authentication stack sat on packages last published in 2013–2015. We reported that as a risk when we assessed it, and it turned out to be a non-event: the packages were finished, not abandoned. Staleness is a list of things to look at, not a verdict, and a report that prints the percentage without the second step is selling the number.

One package is installed and never imported. It costs nothing, and it tells you somebody stopped tidying.

4. Do the tests exist, do they run, and does the pipeline run them?

Three separate questions, and this platform answers them three different ways.

• The admin has no tests. Zero test files. Its test script is configured to pass when it finds none, and its CI pipeline ran that script on every build and reported green. Green meant nothing was checked.
• The backend has 23 tests, and the suite is red. One test broke on 15 November 2023, in the commit that changed the behaviour it checks — the code moved and the test did not. Another was already failing before that. The last commit landed three months later, on top of a red suite.
• The backend pipeline never ran them. Its steps were lint, build, push the image, deploy. No test step. So the red suite was invisible by construction, and had been since the pipeline was last changed, in September 2020.

We checked this by checking out the commits and running the suite, not by reading the pipeline file. A pipeline file says what somebody intended in 2020.

5. Are there secrets in the history?

Clean. Environment files are committed in all three repositories, and every value in them is public by design: client-side keys with a public prefix, feature flags, an analytics project token that ships in the browser anyway.

The first pass said otherwise. A loose pattern match reported four credentials in the history, and every one was a false positive. That is the best illustration on this list of what a due diligence is for. The scanner's output was four; the answer was zero; the difference is somebody reading what the scanner found. A report that forwards scanner output without that step is selling fear, and a buyer who pays for it gets a discount on the price and a wrong picture of the risk.

Seven you can only ask

6. Does it build on a clean machine?

Clone it somewhere it has never been, follow the README and nothing else, and time it.

• Admin: 20-line README. Install 13 seconds, build 22 seconds, green.
• Backend: 18-line README. Install 17 seconds, build 7 seconds, green.

Under a minute each, which is a good result — and the least informative good result on this list. The README says nothing about which Node version to use for the admin; the backend's manifest asks for 18, so we used 18 for both and it happened to work. The backend needs a database to actually run, and there is a compose file for that, though the README does not mention it. And none of this touched the app, which is the repository that took 346 changed files to wake. Install and build is the floor. What a buyer is paying for is whether the thing runs, and that is questions 7 and 9.

7. Who holds the keys?

The code names eight outside services: a database host, a cloud account and container registry, a push notification provider, a translation service, an analytics service, a transactional email service, a video host and a CI provider. One of the eight, the CI provider, shut down on 31 January 2026. The pipeline both repositories document deploys through a company that no longer exists.

Nothing in a repository says whose login each of the other seven is under. In our experience it is frequently one person's, on a private email address, and that person is often the one who left. Ask for the list, ask who can log in to each today, and ask what happens to the account when they cannot. This is the question that most often turns a good technical picture into a bad first month.

8. Who owns it?

Who wrote the code, and under what agreement: employees, contractors, a previous agency, a friend of the founder. Whether the contracts assign the work. What was copied in from elsewhere and under which licence. Whether any dependency carries a licence that reaches into the product.

This is a legal question with a technical surface, and it is the most expensive one on the list to get wrong, because it is the only one that can make the codebase not the seller's to sell. We ask it and we hand the answer to the lawyers; we do not judge it ourselves.

9. Where is the data, and has anyone ever restored it?

Where customer data lives, what personal data is in it, whether backups exist, and whether anybody has ever run a restore from one. The last part is the one that matters. A backup nobody has restored is a hope. There is a folder for database dumps in this platform's compose file, which tells you dumps were taken at some point and nothing else.

10. What does it cost to run, and where does it break?

The hosting bill today, and what happens at ten times the load. A buyer who plans to grow the product is buying the second number, and it does not appear in any repository.

11. What is the verdict?

Not a score. A score lets the reader skip the reasoning, and the reasoning is what they paid for. The document answers the buyer's four questions in order: what are we buying, what does it cost to keep alive, what could go wrong, and who are we dependent on. Each answer names the evidence it rests on and which of the twelve it came from.

12. What has to happen in the first ninety days?

The list the buyer actually uses. For this platform it would have started: replace the CI, because it is gone; delete or fix the two red tests, so that the suite can mean something again; write the tests the admin does not have, or admit it never will; pin the Node version in the admin; find out whose name is on the seven accounts.

What the scanner would have said

Every automated signal on this list was wrong in the direction of confidence. The secrets scanner found four; there were none. The admin's CI said green; it had checked nothing. The backend's test runner reported 46 tests; it was 23, run twice from two directories, with two of them broken. The staleness number said 40% and meant a list of things to read.

The five repository questions take a day, and a tool can produce something that looks like them in an hour. The seven others take a conversation with people who may not want to have it. A due diligence is the second part. The first part is how you know which questions to ask.