Send a founder a forty-page specification and a link to something they can click. I know which one comes back with questions by the end of the day, and it is never the PDF.
That’s not a complaint about founders. It’s how people work. A document asks you to imagine the product and then judge your own imagination. A demo asks you to use it and notice what feels wrong. The second is much easier, and it surfaces far better questions.
So on early-stage hardware projects, I’ve moved most of the “documentation” phase into something you can press.
What a spec misses
Hardware specs are good at listing what a product has: a button, a ring of LEDs, Wi-Fi, a battery, an app. They are much worse at describing what the product does when things get messy.
What happens when the button is pressed twice while the motor is already running? What does the app show when the device hasn’t been heard from in ten minutes? If a scheduled action is due and the internet is down, does the device go ahead or wait? Who wins when the app and the device disagree?
None of those are exotic. They are the questions a user runs into in the first week. In my experience they’re rarely in the spec, because nobody thinks to ask them while staring at a list of features.
On a schematic, these behaviors look free. On a shipped product, every one of them is a firmware decision, an app screen, a support ticket, and sometimes a hardware constraint: a way to detect a jammed motor, a clock that keeps time without the network, enough memory to queue events while offline.
What a preview changes
A prototype preview is a browser simulation of the product’s behavior: the device, the app, and the logic connecting them. It’s not a render and it’s not a mockup. Buttons do things, timers run, the connection can drop, a fault can be injected. The logic is the same logic the firmware will implement.
I first built one so a client could press buttons, watch light sequences and walk through the product’s modes before the physical prototype shipped. It worked well enough that it became the pattern: the preview now comes first, in week one, before any part is ordered.
Three things happen when a founder gets one.
They test instead of approving. Reviewing a spec, people check that their features are listed. Clicking a preview, they try to break it. That’s the review you actually want.
Arguments get specific. “It should handle offline gracefully” turns into “keep feeding on schedule, store the events, sync when back, and show ‘offline’ in the app instead of a stale number.” That sentence goes straight into the firmware requirements.
Other people get involved. A link travels. Co-founders, investors and a few target users can all try it on their phones. Nobody forwards a spec to their target users.
Less paper, not no paper
I’m not against documentation. I’m against documentation that exists to prove work happened.
What survives the preview phase is short and useful: the behaviors the client approved, written as scenarios. “When the hopper drops below 20%, the device turns amber and the app gets one alert.” Those scenarios become the firmware spec, and later the test plan for the physical prototype. Same sentences, three jobs.
What disappears is the long description of a product nobody has touched yet.
What it doesn’t do
A preview models behavior, not physics. It won’t tell you the battery lasts a year, the radio reaches the garage, or the motor has enough torque for a stubborn kibble. Those still get measured on a bench, with real parts, and sometimes the answers hurt.
But by then we’re measuring a product whose behavior is already agreed. When a measurement forces a change, we know exactly which behaviors it touches, because they’re written down as scenarios rather than buried on page 23.
If you want to see what this looks like, I built a fictional example: Munch, a connected pet feeder with its phone app, complete with Wi-Fi drops and a jammed motor. Try the prototype preview.
The part I care about
I like surprises. Just not on a client project.
Every hardware project has a few, and the only real question is when they show up. In week one, a surprise costs a dropdown and a sentence in a spec. In week eight, it costs a board revision, a few weeks, and some trust. The preview is simply the cheapest place I’ve found to have them.