The Prototype Graveyard: Why Cheap Demos Kill Good Ideas

The short version

Prototype-first is my thesis. When building collapses to nearly free, the working prototype beats the written argument, and I have made that case across this whole site. This post is the asterisk I owe it. Cheap prototyping has a failure mode almost nobody who advocates for it, including me, names clearly: when building is free, the demo quietly replaces the argument, and good ideas die because a rough first prototype made them look like bad ideas. The graveyard fills with strong concepts killed by weak demos, because no one stated what a fair test would even be before opening the editor. The fix is not prototyping less. It is stating a falsifiable claim before you build, so the prototype tests a hypothesis instead of becoming an unearned verdict. Here is how good ideas die, and how to stop killing yours.

I argue for prototype-first development everywhere. PRD as output, not input. The working prototype as the argument. Build to learn instead of speccing to death. I believe it, I run my company on it, and it is right for where software is going.

It also has a body count, and I do not see the people selling prototype-first, me included, talking about it honestly. So let me walk you through the graveyard.

How a good idea dies in the graveyard

Here is the death, step by step, because it is always the same.

Someone has a genuinely strong idea. Building is cheap now, so instead of arguing for it, they build a quick prototype over an afternoon. The prototype is rough, because it was an afternoon. It gets shown in a review. The room reacts to what is in front of them, which is a rough thing, and the reaction is lukewarm. The idea gets shelved. Everyone feels rigorous because hey, we prototyped it and the prototype was not compelling.

But nobody tested the idea. They tested a rushed first rendering of the idea, in a room that could not separate the two. A weak prototype of a strong idea reads as a weak idea. That is the whole tragedy. The cheapness that let them build it fast is exactly what let them kill it fast, for a reason that has nothing to do with whether the idea was good.

“

A rough prototype of a strong idea reads as a weak idea. The graveyard is full of concepts that were never tested, only rendered badly and buried.

”

Why cheap building makes this worse, not better

The counterintuitive part is that expensive prototypes used to protect against this, and cheap ones removed the protection.

When a prototype cost three weeks of engineering, the cost itself forced a conversation before anyone built. What are we trying to learn. What do we actually believe. Is this even worth the three weeks. That friction was annoying, and it was also doing real work: it made the team articulate a hypothesis before committing. You could not afford to build without a reason.

Now you can. Building is an afternoon, so the friction is gone, and the forced hypothesis went with it. Teams generate five prototypes in a week and learn nothing from any of them, because no one ever said what each one was supposed to prove. This is the line I keep coming back to, and I mean it as a criticism of my own thesis: cheap building makes undisciplined teams more prolific, not more correct. The assumption you never stated cannot be tested by a demo, no matter how many demos you crank out.

“

Cheap building makes undisciplined teams more prolific, not more correct. The friction we removed was also doing the thinking.

”

The substitution nobody admits to

Underneath all of this is a swap that happens silently. Teams believe they are building to learn. They are actually building to decide.

Building to learn means the prototype is a question. It is an instrument pointed at a specific hypothesis about a customer, and its job is to return a signal. Building to decide means the prototype has quietly become the decision itself: if it looks good in the demo, the idea is approved, and if it looks rough, the idea is rejected. The production values become the verdict.

The graveyard fills up entirely from this confusion. Teams think the demo is testing the idea when the demo is just rendering it, and they let the rendering decide. A polished prototype of a mediocre idea sails through. A rough prototype of an excellent idea gets buried. Both are the same error: letting how the thing looks stand in for whether the thing is true. This is the same trap I warn about with shipping vibe-coded features, pointed inward at your own roadmap instead of at your customers.

The fix is one sentence, before the editor

You do not fix this by prototyping less. You fix it by reinstalling the friction the cost used to provide, deliberately, as a habit.

Before you build anything, write one sentence. I believe this specific user will do this specific thing for this specific reason, and I will be wrong if they do not. That is it. A falsifiable claim, stated out loud, before the editor opens. Now the prototype has a job that is not just to look good. Its job is to make that sentence true or false. When you show it, you are not asking "do you like this," you are asking "did the user do the thing I claimed." The demo stops being a verdict on the idea and goes back to being a test of a hypothesis, which is what it was always supposed to be.

And in the review room, hold the two things apart on purpose. Judge the idea against the claim, and judge the prototype as a rough first instrument. A great idea behind a clumsy build is not a dead idea. It is an idea whose first instrument was clumsy. Say that sentence in the room, every time, because the room will not separate them on its own. This is the discipline underneath the whole outcome-to-prototype loop: the loop only works if a claim sits at the front of it.

I still believe building beats arguing. But a prototype that replaces the argument instead of testing it is not building to learn, it is theater with better production values, and it kills more good ideas than slow discovery ever did. State the claim first. It is one sentence, and it is the difference between a prototype that tests your idea and a graveyard you fill without noticing.

Before your next prototype this week, write the sentence. One claim, falsifiable, out loud, before you open the editor. If you cannot write it, that is not a signal to build faster. It is a signal you do not yet know what you are testing.

Sources: Teresa Torres, on assumption testing · Marty Cagan / SVPG, on building to learn versus building to earn · Tom Chi, on rapid prototyping discipline