Prototyping

Building something deliberately cheap and incomplete to answer a question before committing to the real thing. A prototype trades fidelity for speed: just enough to test value with users, probe usability, or check feasibility, and no more. It is meant to be thrown away once it has taught what it was built to teach.

Why it Matters

The cost of being wrong falls dramatically when you can test an idea in hours or days instead of months. Prototypes put a question to reality, will people use this, can this be built, before expensive engineering, so that delivery effort goes only to ideas that have already survived a cheap test. The discipline is choosing the lowest-fidelity prototype that answers the specific risk in question.

Signals

• Big builds committed on the strength of opinion, with no cheaper test attempted.
• Prototypes polished far beyond what the question required.
• A prototype quietly shipped as the product because it looked done.

Benefits

Fast, cheap answers to risky questions, evidence that replaces argument, and protection against pouring engineering into ideas that a day of prototyping would have killed.

Risks

Mistaking a prototype for a product and shipping it; over-investing in fidelity that the question did not need; learning the wrong thing from an unrealistic test.

Tensions

A prototype must be realistic enough to give a trustworthy answer yet cheap enough to throw away; the pull to keep and extend a promising prototype undermines both.

Examples

A clickable mock that tests whether users understand a flow before any backend exists; a feasibility spike that probes a risky integration before the team commits to it.