In product development, what is the difference between a throwaway and an evolutionary prototype, and what risks does each carry?
answer
- built to learn versus built to keep
- speed over quality, then delete
- the demo that quietly ships
- production standards from day one
- decide its fate before building
basics
~20 sA throwaway prototype is built quickly to answer a question and then discarded; an evolutionary prototype is built to production standards and grown into the product. Throwaways risk being shipped; evolutionary ones risk slow, premature commitment.
solid answer
~50 sA **throwaway** (or rapid) prototype exists to **learn**: it cuts every corner that does not affect the question — fake data, no error handling, no tests, no accessibility work — and is deleted once the question is answered. That makes it fast and makes exploring radically different ideas cheap. Its classic risk is that it **impresses someone and ships**, carrying all the skipped work into production. An **evolutionary** prototype exists to be **kept**: it is built on the real architecture and to production standards, then grown release by release. It suits cases where requirements are fairly well understood and the core will survive. Its risks are the opposite: it is slower, it **commits early** to an architecture and a direction, and sunk cost makes teams reluctant to explore alternatives. The discipline is to decide which kind you are building **before** you start, and say so to everyone who sees it.
go deeper
Recall that a throwaway prototype is built to learn and then deleted, while an evolutionary prototype is built to production standards and kept.
Explain which corners a throwaway may cut, when each type fits, and the opposite risks: shipping the throwaway versus committing early.
Show how you handle the stakeholder who wants to ship a throwaway, and how you validate direction before committing to an evolutionary build.
Set expectations across the organisation so prototypes are declared as throwaway or evolutionary, and fund the real build rather than hardening demos.
## Two purposes Prototypes are built for one of two purposes, and confusing them causes most prototype-related trouble. - A **throwaway prototype** — also called a rapid prototype — is built to **answer a question** and then discarded. Its value is the knowledge it produces. - An **evolutionary prototype** is built as the **first version of the product** and refined over successive iterations. Its value is the code and design that survive. Both are legitimate. They call for different construction standards and carry opposite risks. ## Throwaway prototypes Because the prototype will be deleted, anything that does not affect the question can be faked or skipped: - hard-coded or fake data instead of a real inventory service; - only the happy path, with no error handling; - no automated tests, no performance work, incomplete accessibility; - whatever tool or technique is fastest, even if it would never be used in production. This makes throwaways **fast**, and it makes **comparing radically different concepts** affordable — a car-rental team can build three competing search experiences in the time one production-quality version would take, and learn which direction deserves investment. **Risks:** - **The demo that ships.** Stakeholders see something that works on screen and ask why it cannot go live next week. If it does, every skipped corner becomes production debt, including security and accessibility gaps. - **Over-building.** Teams gold-plate a throwaway until it is too expensive to discard. - **False confidence.** Fake data and instant responses can make an idea look better than it will be with real constraints. ## Evolutionary prototypes An evolutionary prototype starts from the real architecture and is built to production standards, then grown: - it uses real data sources and real integration points from the start; - it carries tests, error handling and accessibility work as it grows; - each iteration adds or refines features on the same base. It suits projects where the **core requirements are reasonably well understood** and the question is more about refinement than direction. **Risks:** - **Premature commitment** to an architecture or concept before the direction is validated. - **Slower learning**, since every experiment pays production costs. - **Sunk cost**, which discourages exploring alternatives the team has already invested against. ## Comparison | | Throwaway | Evolutionary | |---|---|---| | Purpose | Learn and discard | Keep and grow | | Quality bar | Only what the question needs | Production from the start | | Speed | Fast | Slower per experiment | | Best when | Direction is uncertain, concepts compete | Direction is clear, refinement remains | | Main risk | Gets shipped as if it were the product | Commits early and resists change | ## A car-rental illustration A car-rental team is unsure whether customers want to search by location first, by dates first, or by picking a car first. It builds three throwaway prototypes in a few days, each with fake inventory and only the happy path, and learns that most people start from where and when they need the car. The team then starts an **evolutionary** build of the location-and-dates search on the real inventory service, with tests and accessibility work from the first iteration. The throwaways are deleted; what carries forward is the decision, the task findings and the content that worked. Had the team started evolutionary, it would have paid production costs on two directions it then abandoned; had it shipped a throwaway, fake inventory and missing error handling would have reached customers. ## Practices that keep each honest 1. **Declare the type up front** — in the kickoff, in the file name, on the demo's first screen. 2. **For throwaways, set an end**: the question it answers and the date or event after which it is deleted. 3. **When a throwaway impresses**, explain what it skipped and plan the real build, reusing the learning rather than the code. 4. **For evolutionary builds, validate direction first**, often with throwaway prototypes, before committing the architecture. 5. **Revisit the decision** if an evolutionary build keeps being rewritten; it may really be a series of throwaways. The distinction applies equally to prototypes built as linked screens and to coded prototypes on the web or native mobile; what matters is whether the artefact is meant to survive.
- Can a throwaway prototype's code ever be reused?Pieces sometimes can, but only after being brought up to production standards as deliberately as new code would be. The safe default is to reuse the learning — the validated flow, content and decisions — and rebuild, because the corners cut for speed are rarely visible in the code itself.
- How do you stop stakeholders treating a throwaway as nearly done?Say what it is before showing it, make its rough edges visible, and list what it skipped: real data, error handling, tests, accessibility, performance. Pair the demo with the plan for the real build so enthusiasm turns into funding for that plan rather than a request to ship the prototype.
saying these in an interview costs you the question
- A prototype that works in a demo is most of the way to production.
- Evolutionary prototyping is always better because nothing is wasted.
- Throwaway prototypes are wasteful because their code is deleted.
- Whether a prototype is kept can be decided after it impresses stakeholders.
- An evolutionary prototype can skip tests and error handling until later.