It worked in the demo

The demo went perfectly. Everyone in the room watched the new automation run start to finish without a hitch, and everyone left convinced the thing was ready. Then it went into production, a regular operator loaded a regular file, and it broke on the first pass. Not a dramatic failure. A quiet one: an unrecognized encoding, a scanned PDF instead of a clean export, a field left blank because nobody filled it in that week. The system stopped, and nobody in the room that first day had known to expect it.

The instinct after a failure like that is to fix the specific thing that broke. Someone finds the file that caused the crash, writes a patch for that exact format, ships it, and moves on feeling like the gap is closed. It rarely is. The next week brings a different oddball, an encoding nobody anticipated or a field structured slightly differently, and the same class of failure happens again under a different name. Patching file by file treats each break as an isolated bug instead of what it actually is: a signal that the system was never built to handle the range of input a normal week actually produces.

The demo itself is the root of the problem, not the failure that follows it. A demo is run by the person who built the system, using the file they know works, on a day they chose. It is a rehearsal with a stacked deck, and a stacked deck proves the system can succeed once, under ideal conditions, with an expert at the controls. It proves nothing about Tuesday, when a different person who was not in the room loads whatever file actually landed in their inbox, in whatever shape it happens to be in.

The fix was to stop letting the one person who knew which file to load be the only test the system ever passed. It meant feeding it the messy files an average day actually sends: the scan instead of the clean export, the wrong encoding instead of the expected one, the blank field instead of the filled one. It meant walking every input path and asking not "does this work when the file is right" but "what happens when it is not," and building an answer for that case before the system ever meets a real user. The standard changes too: a build is not finished when it works on the demo file, it is finished when it survives the file nobody planned for.

The concrete change was routing every failure to the team instead of back to whoever built the thing. When the system meets input it cannot process cleanly, it does not fail silently, and it does not become one more thing only the original builder can diagnose. It gets caught and flagged for whoever is actually watching, so the system stays resilient even when the person who built it is unavailable, and no single person becomes a new bottleneck in place of the old one.

Fewer things break on a normal Tuesday now, because the system was built for Tuesday and not for the demo. The ones that still do get caught by the team, not buried quietly in a log nobody reads until a client asks why something went wrong three weeks ago.