Tracer Bullets Beat Prototypes

Both techniques exist to reduce uncertainty early. They are not interchangeable, and picking the wrong one costs weeks.

The difference

A prototype is built to be discarded. You cut every corner that isn't the question you're asking: hardcode the auth, fake the API, skip the errors. Its only job is to produce an answer, and its value ends the moment you have it.

A tracer bullet is thin but real. It connects every layer of the system end to end -- UI, transport, service, storage -- with one narrow feature that genuinely works. Nothing is faked. It is just small.

Prototype:      [ elaborate UI ] --> (hardcoded JSON)

Tracer bullet:  [ one button ] -> [ route ] -> [ service ] -> [ real DB ]

Why the tracer usually wins

The risk on most projects isn't "can this screen look right". It is "do these five pieces actually fit together". A prototype answers the first question and leaves the second untouched until integration week, which is exactly when it is most expensive to discover the answer is no.

The tracer bullet hits the integration risk on day one. After that, every subsequent feature is an addition to a working skeleton rather than a bet on one.

It also gives you something a prototype never does: a deployable artifact from week one. Stakeholders can use it. It runs in CI. It has a real error path.

When a prototype is still correct

• The question is purely visual or interaction-level.
• You are comparing three libraries and will keep at most one.
• The unknown is genuinely disposable -- "will this API even return what we need?"

The failure mode is not building prototypes. It is building a prototype, showing it to someone, and then being asked to ship it. Once that happens the corners you cut become permanent, and you are maintaining a demo.

The rule I hold to: if there is any chance the code survives the meeting, make it a tracer bullet.