In The 99% that stays in the drawer I argued that unfinished work is often tuition, not shame. This is the other side: the 1% that shipped. Shipping is not the win by itself. Shipping without a way to know you were wrong is theater with a deploy badge.

"Works in the demo" is not success

A happy path on my machine, a clean recording, a slide that says "80% time saved" with no baseline — none of that is success. Success is a claim that can die when reality shows up. If you cannot write the kill condition before you write the happy path, you are building a story. Stories belong in decks. Systems need falsifiers.

Define the falsifier before you code

Before a script, a tool, or a product path gets serious time, I want one sentence: I would turn this off if _____. Examples that count:

• Rework after "done" stays above the manual baseline for two weeks.
• Operators still hop across the same number of contexts to finish the job.
• Time-to-ready-for-human-judgment does not drop in the queues we care about.
• Failure is silent more than once in a real week.

Vague vibes ("people seem happier") do not count. If you cannot measure the kill condition, you cannot claim the win.

Three metrics I actually use

1. Rework — how often "finished" comes back.
2. Context hops — how many portals, tabs, or handoffs remain.
3. Time until judgment — how long until a human can decide, not how long until a spinner stops.

These map to the same allergy I wrote about in A milestone that wasn't a job title: people hired for judgment should not live as typists. Automation that only moves typing around is not automation.

Small tool vs company product — same bar, different user

On tools.danieldiaz.dev, the user is often me. The kill condition can be personal and strict (if capture takes too long, the tool failed). On ECORPA, the kill condition is about other people's hiring timelines. Same rule shape. Different blast radius. That is why the surfaces stay separate — see why tools lives apart from ECORPA.

What the 1% taught that the drawer could not

The drawer teaches constraints and dead ends. The 1% teaches contact with reality: which kill conditions fire, which metrics were fantasy, which "obvious" features never earned their keep. The builds that matter share that pattern. They survived a falsifier. The rest stayed useful as negative space.

Checklist before the next ship

1. Write the kill sentence first.
2. Name the baseline you are comparing to.
3. Decide what fails loud vs what fails closed.
4. Cap blast radius so one bad dependency cannot freeze everything.
5. Ship the smallest loop that can die honestly.
6. Schedule a date to read the falsifier — not a date to celebrate the launch.

If that list feels heavy, good. It is lighter than maintaining a story that operators already stopped believing.