Six warning signs in a codebase you are about to buy, checked across 32 of them

You do not need to read code to get a first picture of a codebase. You need six answers, each of which a developer can pull out of the repository in under a minute, and each of which you can read yourself. We ran the six over every codebase on our own disk that qualified — 32 of them, 19,513 commits, 79 years of combined history from 2016 to this month — to see how common each warning sign actually is. The short version: the median codebase shows two of the six, one shows none, and the one that shows none is the worst codebase in the set.

What the sample is

Every git repository on one of our machines with at least twenty commits, duplicates removed. Clients' systems we took over, systems we built, systems that are live today and systems nobody has opened in three years. Small marketing sites and platforms with a mobile app, a backend and an admin. It is not a survey of the industry; it is what one agency has actually touched, which is also what a buyer is looking at — a specific codebase with a specific history, not an average. Nothing here names a client.

The six

1. When was it last touched, and how long was it ever left alone?

Ask for the date of the last commit, and for the longest gap between any two commits. Both are one command.

15 of the 32 had not been touched in over a year at the time we looked; 10 had not been touched in two. Looking back through their histories, 17 had at some point gone six months without a commit, and 6 had gone more than a year.

How to read it: code does not decay while it is left alone. Everything around it does — the language, the libraries, the app stores, the hosting. A long silence is not a sign the code is bad. It is a bill for catching up, and the size of the bill scales with the silence.

2. How many people have worked on it, and how many are still there?

Ask how many distinct people appear in the history, what share of the commits the biggest contributor made, and how many people were active in the final year.

In 20 of the 32, one person made at least half of all commits. Restrict that to the 25 codebases that had more than one author at all, and it is still 13. In 14, two people or fewer were active in the final year; in 10, exactly one.

How to read it: you are buying the code, not the person, and in most of these the person is the one who knows where everything is. Ask whether that person is part of the deal. If the answer is no, the number to negotiate over is how long it takes somebody else to become that person.

3. Are there any tests?

Ask whether the repository contains automated tests. Not whether they are good, not whether they pass — whether any exist at all. That is a file count.

22 of the 32 have none. Among the 17 substantial ones, with two hundred commits or more, 9 have none.

How to read it: no tests means every change is checked by a person clicking through the product, or by nobody. That does not make the code wrong; it makes every future change cost more and makes the person in sign 2 harder to replace. Tests that do exist tell you nothing until somebody runs them, which is where the technical checklist takes over.

4. Is there a file that says how it gets to production?

Ask whether there is a pipeline definition — a file in the repository that describes how the code is built, checked and deployed. If there is one, a machine has been doing that job. If there is not, a person has.

8 of the 32 have no such file. Among the 17 substantial ones, only 1.

How to read it: this is the one that has improved most. A missing pipeline in a small site is ordinary. A missing pipeline in a system of any size means the deployment procedure lives in somebody's head, and you should ask whose.

5. Can a stranger start it?

Ask how long the README is. It sounds trivial, and it is the fastest proxy there is for whether anyone ever expected somebody else to work on this.

7 of the 32 have a README of ten lines or fewer, and 4 of those have none at all.

How to read it: the codebase was written for the people who wrote it. That is normal for a system with one author and a warning for one you intend to hand to a new team. Ask the seller to have somebody who has never seen the code start it from the instructions alone, and time it.

6. Is the parts list frozen?

Every modern codebase depends on hundreds of packages written by other people. A lockfile records exactly which versions were used, so that the same code builds the same way next year. Ask whether there is one.

31 of the 32 have one. This sign is nearly universal now, which is exactly why its absence is loud: the one without it is a system that may not build the same way twice.

How the 32 scored

Count the warning signs each codebase shows out of the six above:

• None: 1 codebase.
• One: 9.
• Two: 14.
• Three: 6.
• Four or more: 2.

So a codebase with two warning signs is the median, not a problem, and a buyer who walks away at the first sign walks away from most of what is for sale. The count is for sorting a pile, and for deciding which candidates get the full technical checklist rather than which get rejected.

The one that passed

The single codebase with none of the six warning signs is a backend we know well. Eleven authors over five and a half years, six of them active in its final year. Tests present. A pipeline definition present. A lockfile, a README, and its longest silence under a year.

It is also the backend from the previous article: its test suite had been red since November 2023, the pipeline it documents never ran the tests, and the company that ran that pipeline shut down in January. All six signs green, and the three things the signs were standing in for were broken.

That is not an argument against the six. They put this codebase in the right pile — the one worth a proper look — and the proper look found the problems in a day. It is an argument about what the signs are for. They tell you where to spend the expensive attention. They cannot tell you what it will find.

What to do with this

Ask the seller for the six numbers before the first technical meeting. Any developer can produce them in a quarter of an hour, and a seller who cannot has told you something already. Count the signs. Then spend the technical due diligence on the two or three candidates worth it — and read the result knowing that the codebase with the cleanest surface was the one with the most underneath.