Prototypes often appear after a direction is mostly settled, used to explain an interaction or build consensus. I increasingly prefer to start earlier—not to present an answer, but to expose the question.
Real constraints reveal the product
On a canvas, every state can be arranged perfectly. In a browser, content length, loading time, keyboard input, and screen size happen at once. They are not details reserved for implementation; they are part of the product itself.
Writing a small amount of real code lets me see assumptions that static frames keep hidden.
Not production-ready, but experientially honest
A thinking prototype does not need a complete architecture. It needs the right friction: real data, repeatable states, believable response time, and enough continuity for someone to forget that it is a demo.
The most valuable prototype is not the most complete. It is the one that helps a team discard a bad assumption fastest.
The interesting space between design and development is not that one person can do two jobs. It is that two media can participate in the same act of thinking.