Five green test suites, zero deploys

My newsletter engine prints a line every morning that counts the days since I finished a system and never deployed it. Today it says five systems, thirty-two to thirty-seven days. Every test suite is green. The counter works perfectly. That is the whole problem.

The counter I built to nag myself

A few weeks ago I added a section to my own daily briefing: top open ideas, and underneath, a quiet line listing everything I had built and never deployed, with a day count next to each entry. The idea was that visible debt gets paid.

It does not. The counter has been running every morning since. The numbers only go up.

What is actually in the pile

Five systems. A payment-recovery tool, ninety-eight tests green. A contact watcher, fifty-nine. A voice-fingerprint checker, seventy-two. An agent-run observability CLI, seventy-five. A matchday content pipeline, thirty-three. All built with a spec, a plan, a review gate and test-driven implementation. None of them is a prototype. None of them is deployed.

The reflex explanation is procrastination, and it is wrong. I found the better explanation by looking at the one entry the counter gets wrong.

"Deployed" is the wrong binary

One of those five allegedly undeployed systems has been producing real, verified output in a live environment for weeks. Actual content, actual drafts in an actual publishing system, checked by ID. It counts as never deployed because there is no deploy record. I start it by hand, from a terminal, when I remember.

So the binary is wrong. The honest scale has three rungs:

• It runs when I run it.
• It runs without me.
• Someone notices when it breaks.

Rung one is where finished code lives. Almost everything I build reaches it on the day it passes its tests. Rung two and rung three are a different kind of work entirely.

What the last mile actually contains

I went through the five and wrote down what stands between rung one and rung two for each. Not one item is code.

• A data-processing agreement and a competition-law review before the first real payment run touches a customer.
• A live probe across twenty companies against a seventy-percent hit-rate target, because the tool is worthless if it is right half the time.
• A blind test, eight out of ten, before I trust a scoring model on someone else's writing.
• A scheduler, and a hosting environment that belongs to somebody else.
• A token I exposed during setup and never rotated.

That is the last mile. It is legal exposure, evidence, access, and consequence. An agent can write the code for any of these in an afternoon. None of them can be delegated, because what they actually require is someone willing to be accountable for an unattended system.

Rung three is where I keep getting caught

I have the receipts for this one. A flag I set for a dry run and forgot: the cron ran green every day for thirteen days, every stage passed, and no newsletter went out. The task status was healthy the entire time. I had been checking the wrong artifact. Separately, my weekly pipeline sat silently dead for three weeks. Both were found by accident, not by an alarm.

The lesson that survives is uncomfortable in a year when everyone is celebrating how fast they can build: a healthy job status proves that something ran, not that anything arrived. Until a failure produces a signal that reaches a human, rung three is empty, and rung two is a liability rather than an achievement.

What I changed

Two things, both boring. First, done now means rung three, and a build that stops at rung one is written into the ledger as unfinished rather than shipped. Second, one deploy before the next build. Not because the backlog is precious, but because five finished systems on a shelf are not proof of productivity. They are proof that I optimised the cheap half of the work.