Comparisons
Pairs engineers genuinely confuse — goal and implementation, MVP and bad prototype, prototype and spike, reversible and irreversible. Neither column wins; what decides is the problem. Each record leads with the confusion, because the confusion is what it costs.
Prototype vs spike
Both are called "a prototype" and both are allowed to be ugly, so the spike grows into a prototype and the prototype grows into the product, and neither ever answers its question because the question was never written down. The cost is the three-week prototype that has become the codebase, with every shortcut the investigation allowed now load-bearing. The distinguishing habit is the same for both: write the question, the prediction and the time box before starting, and stop when the question is answered. A spike that answered its question on day one and continued to day five was four days of building a product without requirements.
When the question is "would this work for users?" or "does this design hold together?" — it needs enough of the real shape to be judged.
When the question is "can this library do X?" or "how does the provider behave on timeout?" — it needs a repository you will delete and a clock.
| Aspect | Prototype — a working thing built to answer a question about the product or the design | Spike — a time-boxed investigation built to answer a question about feasibility or a technology |
|---|---|---|
| Question | "Does this design or flow work?" | "Is this feasible, and how does it behave?" |
| Time box | Days to a couple of weeks | Hours to a couple of days |
| What survives | The learning and possibly some code | The learning only; the repository is deleted |
| Shape | Enough of the real workflow to judge | The narrowest call that exercises the doubt |
| Example | A checkout flow with a fake payment, shown to five customers | One call to the provider with the network cable pulled |
| Typical mistake | Shipped as the product | Never time-boxed, becomes a prototype |