The Second Version Test: can your team ship v2 without the people who built v1?
Five questions that tell you whether the software you just paid for is an asset or a liability. Run them before the handover call, not after.
The short answer
Software is only finished when someone who did not build it can change it. Five checks tell you whether yours passes: deploy, onboard, scope, failure, and escalation. Run them before you sign off, because every one of them is cheap to fix before handover and expensive after.
Most software does not fail at launch. It fails about eight months later, when the first real change arrives and nobody left in the building knows how to make it. The build worked. The handover did not.
The Second Version Test is five questions we run against our own work before we hand anything over. They take an afternoon. They are all cheap to fix before a handover and expensive to fix after, which is exactly why they get skipped.
Check one: can someone who did not build it deploy it today?
Not in principle. Today, on a laptop that has never had the project on it. Give a new engineer the repository and a credentials vault and time how long it takes to get a running environment and push a trivial change to staging.
The number you want is under a day. The number you usually get is "we will need to ask the person who set it up", which is the answer that tells you everything. Undocumented deployment is the most common single point of failure in delivered software, and it is invisible until the moment it matters.
- Passing: a written setup path, a scripted deploy, secrets in a vault your company controls.
- Marginal: it works, but only from one machine, or only with a person on a call.
- Failing: nobody has tried it since the original build.
Check two: can a new engineer ship something in week one?
Pick a small, real change. A field on a form, a column in a table, a new state on a button. Hand it to someone who has never touched the codebase and watch what happens without helping.
This is the check that catches the thing estimates never name. When every small change takes a week, the cost is not in the change. It is in the hour spent working out where the change goes, and in the four places it has to be repeated because the same logic was written four times.
Check three: is there a written description of what it does?
Not a technical spec. A plain description of the behaviour the software is supposed to have, written in the language your business uses. What happens when a payment fails. What an admin can do that a user cannot. Which of the four date fields is the one that matters.
Without it, every future change is a negotiation with the code about what it currently does, and every answer is an archaeology exercise. With it, disagreements are about the document, which is a much cheaper argument to have.
Check four: does it fail loudly, or silently?
Break something on purpose in a non-production environment. Point the application at a database that is not there, or send it a malformed payload. Then see who finds out, and how.
- Passing: an alert reaches a person, with enough context to act on.
- Marginal: it is in a log somebody could read if they thought to look.
- Failing: a customer tells you, several days later.
Silent failure is the expensive kind. Software that breaks noisily gets fixed in an afternoon. Software that breaks quietly gets fixed after it has been producing wrong answers for a quarter, and then you have two problems.
Check five: who do you call, and do they answer?
Write down the name of the person responsible for this software being up at three in the morning. If the honest answer is a company rather than a person, or if the arrangement lives in goodwill rather than in a document, you do not have support. You have an expectation.
This is the check most teams skip because it feels like paperwork. It is the one that turns into a genuine crisis exactly once, and then permanently changes how that company buys software.
Scoring it
| Checks passed | What you have | What to do next |
|---|---|---|
| 5 | An asset | Nothing. Re-run it after the next major change. |
| 3 to 4 | An asset with a known weak point | Fix the failing checks now, while the people who built it are still reachable. |
| 1 to 2 | A dependency on specific people | Budget a handover engagement before you commission anything new on top of it. |
| 0 | A liability | Stop adding features. The next thing to fund is making it changeable. |
When to run it
Three moments, and the first is the one people miss.
- 1Before you accept delivery. Put the five checks in the contract as acceptance criteria and they get built in rather than retrofitted.
- 2Before you commission the next phase. Adding features to software that fails these checks is how a six-week project becomes a six-month one.
- 3When an engineer resigns. The test tells you what leaves with them, while you can still ask.