A prototype should answer one question

I used to make prototypes too complete.

If I was testing a new dashboard, I built the filters, empty states, settings page, and a polished sidebar before the central interaction had earned any of that effort. The result looked convincing. That was the problem.

A convincing prototype changes the conversation. People start reviewing spacing, colors, copy, and naming before anyone has answered the main question: does this idea work?

The best prototypes I build now are smaller and rougher. They answer one question, then get thrown away or rebuilt properly.

Start with the risk

Every product idea has a risky part.

Sometimes the risk is technical. Can the data load quickly enough? Can the model return useful results with the context we have? Can the editor support the interactions we want without turning into a custom framework?

Sometimes the risk is behavioral. Will users understand what to do next? Will they trust the suggestion? Will they come back tomorrow without a reminder?

Those risks deserve different prototypes. A technical prototype can be ugly and live behind a CLI. A behavior prototype might need a realistic interface and fake data. Treating both the same wastes time.

Before I open the code editor, I try to write the prototype question in one sentence.

"Can someone create a usable report in under 2 minutes?"

"Can we generate a preview before the user loses patience?"

"Does this workflow make sense without an onboarding tour?"

If the question is vague, the prototype will be vague too.

Make the edges fake on purpose

A prototype shouldn't carry the full weight of a product.

If authentication isn't part of the risk, hardcode the user. If billing isn't part of the risk, skip it. If the data model isn't the thing being tested, read from a JSON file.

This can feel irresponsible when you're used to building production software. It took me years to get comfortable with code that I knew I would delete. The trick is being honest about what the prototype is allowed to prove.

Fake edges are fine when they're visible. They become dangerous when the team forgets they're fake.

I like leaving small labels in the UI or code comments that mark the shortcuts clearly:

• Fake data
• Happy path only
• No persistence
• Slow path untested

That keeps the prototype from quietly becoming a foundation.

Don't polish the wrong thing

Polish is expensive because it changes what people see.

When a prototype looks finished, reviewers start behaving like customers. They assume the hard thinking is done. They ask for refinements instead of challenging the premise.

Roughness keeps the right kind of pressure on the work. A gray button, plain layout, and obvious test data all signal that the idea is still in motion. People stay focused on flow, comprehension, and value.

There are exceptions. If the question depends on trust, the prototype needs enough polish to feel credible. A banking flow, AI assistant, or customer-facing analytics page can fail simply because it looks temporary.

Even then, the polish should serve the question. Make it credible enough to test the behavior, then stop.

Throw away more than you keep

The best outcome for a prototype is a clearer decision.

Sometimes the decision is to build. Sometimes it's to change the scope. Sometimes it's to walk away before the idea eats 3 weeks.

That clarity matters more than reusable code. Reusing prototype code often feels efficient in the moment, then turns into a tax.

Shortcuts harden. Temporary assumptions leak into the product. Nobody remembers which pieces were built for learning and which were built for scale.

When a prototype proves the idea, I usually rebuild the production version with the prototype open beside me. The second version is faster because the uncertainty is gone.

What I look for

After a prototype session, I want evidence.

Could the user complete the task without explanation? Where did they hesitate? Did the interaction make the hard part feel easier, or did it move the complexity somewhere else?

For technical prototypes, I want numbers. Time to first result, failure rate, payload size, render cost, and the paths where the approach breaks.

A prototype without evidence is a demo. Demos can be useful, but they don't reduce risk in the same way.

The discipline is stopping

Stopping before the work turns into a product by accident is the hard part of prototyping.

Once the question has an answer, the prototype has done its job. Archive it, write down what you learned, and decide what comes next.

That rhythm has made me faster. I spend less time building impressive versions of weak ideas, and more time giving strong ideas the shape they deserve.