The Demo That Lies

There’s a particular kind of demo that feels like a triumph and functions like sabotage. It’s the polished one. The prototype where every pixel is aligned, the copy is witty, the animations are buttery, and the whole thing gleams. You show it to someone and they light up. “Wow, this looks amazing.” And you’ve just poisoned the well you were trying to drink from.

I want to be precise about the mechanism here, because “polish is bad” is obviously wrong — you ship polish. The problem isn’t polish itself. The problem is polish arriving too early, during the window when you’re still trying to learn whether the thing is worth building at all. Polish is a signal, and it sends the wrong one at the wrong time.

Think about what a glossy demo tells the person watching. It says: this is finished. This is confident. Someone smart already made all the big decisions. And that message quietly reshapes their behavior. Nobody wants to be the person who tells a proud parent their baby is funny-looking. So they soften. They find something nice to say. They critique the button color instead of the premise, because the button color feels safe to touch and the premise feels welded shut. You wanted feedback on the foundation and you got feedback on the paint.

There’s a second, subtler lie, and this one the demo tells you. A high-fidelity prototype makes the product feel real before it is real. You start to believe in it the way you’d believe in something that already exists. Sunk cost sneaks in the back door — not sunk money, sunk conviction. Once you’ve made something beautiful, killing it feels like vandalism. So you defend it. You reframe critical feedback as “they didn’t get it.” The polish didn’t just distort their honesty; it distorted yours.

And here’s the part that stings: the very act of polishing is what stole your feedback window. Every hour you spent perfecting the empty state and the micro-interactions was an hour the idea sat untested. You traded the cheapest possible learning for the most expensive possible attachment.

So what do you do instead? Not “make ugly things” as a rule — that’s cargo-culting the sketch. The real move is to match fidelity to the question you’re asking.

If the question is “does anyone want this?”, the right artifact is almost embarrassingly rough. A hand-drawn flow. A single screen with fake data. A paragraph describing what it does, with no UI at all. Rough things give people permission to push back, because there’s obviously nothing precious to protect. You’re not showing a product; you’re showing a question, and questions invite answers.

If the question is “can people actually use this?”, then yes, raise the fidelity — but only the parts the test depends on. Make the one flow real and leave everything around it as gray boxes. The gray boxes are doing important work: they announce, honestly, “this is not done, tell me what’s broken.”

One tactic I’ve come to trust: say the quiet part out loud before they can be polite. Open the demo with “This is throwaway — I’m trying to figure out if the core idea is wrong, so be brutal, you can’t hurt it.” You’re manually undoing the signal your own craftsmanship sends. Sometimes I’ll even leave one thing visibly unfinished on purpose, a rough edge that gives people a safe place to start criticizing — and criticism, once it starts, tends to keep going toward the things that actually matter.

The deeper reframe is this. Early on, a prototype is not a small version of the product. It’s an instrument for extracting truth from other people’s heads. And like any instrument, it can be miscalibrated. A demo that’s too polished is a scale with its thumb on it — every reading comes back flattering, and every flattering reading costs you a week you’ll want back later.

Build the beautiful thing. Just make sure you’ve earned the right to, by first shipping something rough enough that someone could tell you not to.

The science, to look up: sunk cost fallacy; social desirability and courtesy bias in feedback; and the paper-prototyping / low-fidelity prototyping tradition in HCI (e.g., work on fidelity and user feedback).