Your AI Demo Is the Easy Part.

A twenty-step automated run died at step nineteen last month. Not because a step was wrong — the first eighteen worked, and the twentieth would have too. It died because the machine's boot volume, 228 gigabytes, hit 100% while an external drive sitting next to it had 1.7 terabytes free and unused. The tools writing temporary output had never been told to look anywhere else.

That is the gap between a demo and a system, and it is rarely the part anyone demos.

What a demo does not have to survive

A three-day prototype has to survive one thing: the person running it, on the machine it was built on, with inputs the builder already knows work. A production system has to survive people who were never in the room, running it at hours nobody watched, on inputs nobody thought to try. Our own piece on jagged AI capability names this directly — strong in places, unreliable in ways that don't track with how strong it looked a moment before. The unreliability isn't random. It shows up exactly where the demo never went.

The list a demo skips

Authentication, permissions, data quality, integrations, latency, cost, monitoring, who gets paged when it breaks at 2am — none of these make a demo more convincing, so none of them get built for one. A demo authenticates as whoever is running it, reads data someone already cleaned, and calls services that were up when it mattered. None of that is a shortcut anyone chose. It’s just what “three days” buys, and it buys nothing on the items above.

They're also not optional later; they're the difference between something that worked once and something a business can put its name behind. Support ownership belongs on this list for the same reason — a system with no named owner for “it's wrong and nobody knows why” is a demo wearing a login page. A demo that skips this list isn't behind schedule. It hasn't started the actual project yet.

The night the disk filled up

The disk-fill failure is the honest version of this. Every one of the first eighteen steps genuinely worked — read the right files, made the right calls, produced the right output. Nothing about the logic was wrong. What broke was an assumption nobody had written down: that there would always be somewhere to write a temporary file. Fixing it wasn't a smarter step nineteen. It was making the location configurable and checking free space before writing, which is exactly the kind of unglamorous plumbing a demo never needs and a system cannot ship without.

A smaller version of the same thing happened separately: five projects got created with a plain mkdir, no git init. The scaffolding that tracks whether a step actually happened depends on being inside a repository — it threw fatal: not a git repository on all five, and three genuinely productive steps got marked as if nothing had happened, because the system's own way of checking its work couldn't answer the question. Retries, fallback behaviour, and rollback all assume the system can tell you honestly what it did. That assumption is infrastructure, and it's invisible until the one time it's wrong.

A test before calling it done

Both failures share a property worth naming on its own: neither announced itself. Nothing crashed and nothing was logged as an error. The work simply stopped — and a stopped run looks identical to a finished one until somebody goes and checks. That is the failure mode a demo can never show you, because nobody leaves a demo running long enough to be fooled by it.

Before calling a prototype complete, ask what happens when it runs unattended for a week against inputs you didn’t choose, on a machine nobody is watching. If nobody in the room can answer with a specific failure mode and name what catches it, the honest status isn’t “in production.” It’s “the easy part is finished, and the project starts now.”

The demo worked. Now what? If a prototype is waiting on the boring half — auth, data quality, monitoring, ownership — that is the half we build. Let’s scope what production actually needs. Book a walkthrough.