Why I still prototype things myself

I could delegate more than I do. Between a team and a set of models, there’s rarely a technical reason for me to build the first version of something. I still do it anyway, and it isn’t nostalgia.

A prototype is a question

Most product decisions look obvious in a document and turn out to be wrong in a browser. The flow that read well has a step nobody wants. The data model that looked clean can’t express the one case that matters.

Building the thing is how I find out. A rough version answers more questions in a day than a week of discussion, because it forces every vague decision to become a specific one.

Where the problems hide

The things that sink projects are usually boring: an integration that behaves differently than its documentation, a latency that makes an interaction feel broken, a permission nobody thought about. You meet them early when you build, and late when you don’t.

When I’ve built the first version, I know where those are. That makes me a better reviewer, a better estimator and a better person to argue with about the plan.

Models changed the maths

Prototyping used to be expensive enough that it had to be justified. With models doing much of the typing, a working sketch now costs hours instead of weeks. The trade-off tipped: it’s now often cheaper to build a version and look at it than to debate whether it’s worth building.

The skill that matters is knowing it’s a prototype. It exists to answer a question, and once it has, most of it should be thrown away. The dangerous prototype is the one that quietly becomes production.

What I keep

• Taste. You only develop a sense of what feels right by making many things that don’t.
• Credibility. It’s easier to lead engineers when you still do the work.
• Speed. The shortest path from idea to decision usually runs through something you can click.

Open questions

• At what team size does building it yourself start to get in the way?
• How do you hand off a prototype without handing off its shortcuts?