Throwaway prototyping builds an artifact primarily to answer a question and expects to discard or replace it. Evolutionary prototyping intends to develop a retained implementation through further work. The distinction concerns the intended fate of the code, and it is separate from whether the knowledge, design decisions, test cases, and observations are retained — those survive under either intent, and losing them is a different mistake.
Neither rule holds
Two absolute positions circulate, and the evidence supports neither.
The always-rewrite rule points at guidance warning against copying prototype code directly into production. That guidance is real, and in the case of the GOV.UK Prototype Kit it goes further and prohibits use for live services. It establishes a warning about direct copying and a restriction on one toolkit. It does not establish that every component must be discarded.
The demo-implies-retain rule points at prototypes that became products. Cunningham’s account of WyCash describes exactly that: a system grown incrementally from a working prototype, with mature sections repeatedly revised or rewritten as it went. That is continuity with consolidation, reported as experience. It does not establish that evolution costs less.
Boehm’s treatment is the useful one because it is conditional: an operationally useful and sufficiently robust prototype can become the basis for further evolution where the remaining risks support that path. The condition carries the argument. Remove it and the sentence becomes either of the two rules that fail.
The decision is per component
A project does not receive one label. The identity provider, the storage layer, a calculation routine, and the screen flow have different evidence behind them and different next uses.
Record for each component its present purpose, intended lifetime, users, data, and owner, and mark it discard, evaluate for reuse, or maintain — with an expiry date or a review event attached, so the mark cannot quietly become permanent. Then inventory what reuse would actually require: interfaces, source, datasets, credentials, generated assets, and operational dependencies, along with the permissions and evidence that are missing.
Compare rebuilding against qualifying the existing component for the same target requirements, and estimate migration, validation, support, and retirement as ranges with stated assumptions. Comparing coding time alone reliably favours retention, because coding time is the part that was already paid for.
Then have the receiving team build, run, and observe the chosen path in an authorised test environment, and log where they needed help. A document review is not evidence that the thing operates.
Breadth and depth decide nothing about retention
A horizontal prototype covers a broad range of the proposed experience with limited functional depth. A vertical prototype explores a narrower capability through more of its implementation. This is a scope choice, and it is independent of fidelity, of maturity, and of the retention decision.
It is also independent of appearance. Houde and Hill separate questions about role, look-and-feel, and implementation, and warn that visible refinement does not reliably indicate completeness. A vertical slice can be ugly and real; a horizontal facade can look finished and store nothing.
The selection rule is to use the least elaborate construction that answers the stated question under its constraints. Where the risk is an external interface, substituting a stub leaves that risk untouched no matter how end-to-end the local path looks.
The methods that keep nothing
Three methods produce evidence and no artifact at all, which makes their retention decision trivial and their interpretation the hard part.
Wizard of Oz has a human supply some or all of an apparently automated system’s responses. The 1983 listening-typewriter study did this with a human typist under programmed vocabulary and response constraints, and its authors identified the differences from a possible real recogniser and cautioned against reading high demand into the result. The bias does not run in one direction: a capable human produces answers no planned system would produce, and the same human is slower than the system would be. Specify what the wizard can see, which responses are permitted, and what happens when a participant goes outside the protocol.
Concierge delivers the intended value manually, visibly, before any software exists — Ries describes manually delivering a menu-planning service before building it. What the trial evidences is the manually delivered service under those conditions, including the founder’s personal attention, which is part of the result and has to be separated from it. Automation is a decision with its own evidence requirement, not a graduation triggered by the label.
Fake door offers an entry point toward a capability that does not exist yet and records interest. Savoia, who describes the method, also distinguishes initial interest from continuing use. The measurement discipline is the whole value: report exposure, clicks, follow-up commitment, and delivered use as four separate stages with their own denominators. Where only impressions and clicks are known, that ratio is an event ratio and not a person-level rate, and repeated clicks make it unbounded as a probability. An expression of willingness at a displayed price is not a paid purchase.
Where the decision fails
It gets made by default. Nobody chose, the demo worked, and the artifact acquired users. A service people rely on needs an appropriate transition even where its original label was throwaway, and a risky one should not keep running merely because the replacement decision is unfinished.
Past cost is treated as a reason to keep. The money spent building the component is not evidence about its suitability for the next use. It is the single most common input to the decision and it carries no information about it.
Not to be confused with
Retaining the learning. Discarding an implementation is compatible with keeping every finding, scenario, and test case it produced. Deleting those alongside the code is the expensive error, and it is invisible.
Lower controls. Reduced production fidelity is not permission to expose sensitive data. Prototype access and data handling need controls appropriate to the actual test.