The Difference Between a Demo and a Product Is the Error Path

A working demo is no longer evidence of much, and most people building now know that. What is less widely understood is where the remaining work actually sits, which produces a specific and predictable failure: a product that is impressive for a week and then quietly abandoned.

The gap is the error path. Not the happy path, which modern tooling will carry you through in an afternoon, but every branch where something is missing, malformed, ambiguous, duplicated, or simply weird.

Why the happy path got cheap and the rest did not

The happy path is the case you can describe. You can describe it, so you can ask for it, and asking for it is now most of the work of getting it.

The error path cannot be described in advance, because it is defined by the things you did not anticipate. That is not a limitation of tooling, it is what the word means. The only way to enumerate it is to run real inputs through the thing and watch what happens, which takes calendar time and cannot be compressed.

So the ratio has shifted. Where the working version used to be most of the project, it is now the opening move, and the proportion of total effort sitting in failure handling has gone up sharply even though the absolute amount has not changed.

What users are actually judging

“Most products that feel reliable are not better at the hard cases. They are honest about which cases they will not attempt.”

Not whether your product works. They assume it works, because everything works now.

They are judging what it does when they feed it something odd, which they will do within the first five minutes, usually by accident. A product that handles that gracefully reads as solid. A product that returns something confidently wrong, or crashes, or silently does nothing, reads as a toy, and that judgement is close to irreversible.

Most products that feel reliable are not better at the hard cases.

This is particularly acute for anything with a model in it, because the failure mode is not an error message. It is a plausible, well-formatted, incorrect answer. A user who catches one of those stops trusting every answer they have already accepted, including the correct ones.

The practical discipline

Spend your first real effort on the inputs you did not design for. Feed it the half-filled form, the file with the wrong encoding, the record with two values in a field that should have one, the request in the wrong language, the number that is negative when it should not be.

For each, decide deliberately between three behaviours: handle it, refuse it clearly, or escalate it to a human. All three are acceptable. What is not acceptable is guessing, and guessing is the default behaviour of almost everything built quickly.

Then make the refusal good. A clear refusal is a feature, and it is the cheapest trust you will ever buy. Most products that feel reliable are not better at the hard cases. They are simply honest about which cases they will not attempt.

What this means for who should build

Enumerating failure modes for a specific domain is not a technical skill. It is the knowledge of what goes wrong in that domain, held by whoever has dealt with it going wrong.

Somebody who processed these records for six years knows the twelve ways the data arrives broken, which of them are recoverable, and which require a phone call. That list is the actual specification, it cannot be derived from first principles, and writing it down is more valuable than any amount of additional building.

See why generic AI build prompts fail for the related trap, shipping stopped being evidence for the market context, and audit trails are a feature for the record that makes failures recoverable. The system covers specifying before building.