Prototypes should be cheap to throw away. Most are not.

The purpose of a prototype is to answer a question quickly and then cease to exist. That second half is the part organisations consistently fail at, and the failure is not technical. It is that a working prototype is extremely difficult to justify discarding.

The demo goes well. Someone asks how long until customers can use it. The honest answer — that this is scaffolding built to answer a question and production would take three months — is unwelcome, and there is enormous pressure to find a shorter path. The shorter path is always the same: ship the prototype and improve it later.

What later actually means

Later means never, for a reason that is structural rather than cultural. Once the prototype is in production it has users, and rewriting it delivers no new capability. Every subsequent quarter offers work with more visible value, and the rewrite loses that comparison indefinitely.

Meanwhile the prototype accumulates. Features are added to code written to be discarded, by engineers who have inherited assumptions nobody documented because nobody expected the code to last.

Making disposal possible

• State the question the prototype answers, and the date it will be deleted, before writing any of it. A prototype without a defined end is a first draft with a flattering name.
• Make it visibly unfinished. Hard-coded data, an obviously provisional interface and a clear label reduce the pressure to ship it far more effectively than an explanation.
• Show it to a narrow audience. Wide demos generate expectations that are then expensive to disappoint.
• Write down what was learned, separately from the code. The learning is the deliverable; the code is a by-product.
• If it must survive, decide that consciously and fund the hardening as a piece of work with its own estimate, rather than pretending the transition is free.

When to skip the prototype

There is a case worth naming: where the question is small and the answer is fairly predictable, building the real thing carefully is often faster than building a prototype and then building the real thing. Prototyping has a cost, and it is not always the economical choice.

Prototypes earn their keep where genuine uncertainty exists — about whether users want it, whether the approach works, whether the performance holds. Where the uncertainty is low, the prototype is not risk reduction. It is simply the first version, built to a standard nobody would have chosen if they had known it would still be running in four years.