Build the smallest thing
that makes them believe.

The most useful mental shift in prototyping is to treat the code as disposable from the start. Not because it’s bad, but because its job is to buy information, not to last. A prototype answers questions — is this valuable? is it feasible? did I understand the problem? — and once it has, its value is spent. Engineers who forget this fall into the sunk-cost trap: they lovingly build a prototype into a fragile pseudo-product, then can’t bring themselves to rebuild it properly.

Naming the code “throwaway” up front is liberating. You skip the abstractions, hardcode the edge cases, and use the ugliest thing that works — because you know it’s scaffolding. Speed of learning is the only metric that matters, and every hour spent making a prototype “clean” is an hour not spent learning whether it should exist at all.

The enemy of a fast prototype is horizontal building — polishing every layer across the whole feature set. The move is vertical: pick the single path from input to valuable output, and build just that path end to end, on one real example. A narrow slice that actually works is a hundred times more convincing than a broad mock-up that doesn’t.

This is why the scoping work matters so much: it hands you the exact slice to build. Without it, you’ll build horizontally and run out of time before anything works end to end.

A prototype is the wrong place for adventurous engineering. Reach for the most boring, fastest tools you know cold: a language you’re fluent in, managed services for anything stateful, and hosted model APIs rather than self-hosting. Every novel technology you introduce is a tax on iteration speed paid at the worst possible time.

There’s a caveat: if discovery revealed the deployment target will be on-prem or air-gapped, let that shape even the prototype (e.g. don’t build the demo on a cloud-only service you can’t use later). Boring-and-fast still wins — just pick the boring tools that will survive the move.

Faking is not cheating — it’s prioritization made concrete. Three techniques recur:

The one hard rule is honesty about the capability. It’s fine to hardcode the account, stub the CRM, and manually kick off the job — as long as the thing you’re claiming (“the model extracts these fields accurately from your documents”) is genuinely real and running. Faking the plumbing is prototyping; faking the actual capability is lying, and it destroys trust the moment production reality arrives.

The most productive way to aim a prototype is to build backwards from the demo. Picture the exact moment you want the customer to react — the “so what” — and build only what’s needed to reach it convincingly. Everything on the path gets real; everything off it gets faked or cut.

This has a wonderful side effect: it keeps you honest about value. If you can’t picture a demo moment that would make the customer lean in, you don’t yet understand the value — and no amount of code will fix that. Demo-driven development turns “what should I build?” into the far sharper “what’s the single moment that would make them believe, and what’s the least I need to reach it?”.

Set a demo date early and treat it as immovable. A deadline is the best scope-cutter in existence: it converts an open-ended build into a series of decisions about what to leave out. When to run the demo, and how to run it, is its own craft — covered in scoping and, in depth, the demo playbook.

A prototype’s life ends in one of two ways, and confusing them is a classic FDE mistake. Either it did its job and gets discarded (the value question is answered; its shortcuts would fight you in production), or its core is genuinely sound and you deliberately harden it into a real system.

Default to disposable. The shortcuts that made the prototype fast — hardcoded config, no error handling, a hand-run step — are exactly what make it dangerous in production, and untangling them is often slower than a clean rebuild informed by everything you learned. When you do decide to harden, treat it as a separate project with its own bar: reliability, observability, security, and a handoff plan. That fork — POC to production — is important enough to have its own checklist, because the gap between “it demoed” and “people depend on it” is where a lot of otherwise-successful deployments quietly fail.

Speed is the point of a prototype, and speed is bought by skipping things: error handling, tests, auth, the second data source, anything that is not the question being answered. That is correct engineering. It becomes negligence at exactly one moment — when the demo goes well and someone says “can we just start using it?” — and the way to survive that moment is to have decided beforehand.

What makes the exit enforceable is making the prototype visibly unfit for production rather than quietly unfit. Structural loudness beats a warning in a README, because the README is not what someone reads before wiring it into a scheduled job:

The read-only rule is the one worth being inflexible about. A prototype that only reads can be deleted on a Friday with no consequences; a prototype that has written 4,000 rows into their claims system is now a migration, an audit conversation and a apology, and it got there without anyone approving it.