What should a working prototype actually prove?

Key idea 1 of 6

The demo answers the wrong question

The team has ideas. Sketches, a deck, half a decision, maybe a demo or three, and pressure from somewhere to make one of them real. Nobody can say yet which is worth building, who it helps, or what it would cost to run, because nothing exists that anyone can actually use.

A demo does not fix that. A demo proves the idea can be demonstrated, which was never in doubt. The questions that decide whether to fund it are different ones: does anyone reach for this on an ordinary day, what happens when the inputs are the real ones rather than the ones on the slide, and what does it cost to keep running once the person who built the demo has moved on?

Working software is the fastest way to find out.

Sometimes the risky uncertainty is technical: whether two systems can be made to talk to each other at all, or whether the data will hold up the workflow. Then feasibility is the question, and the prototype is built to answer it. More often, on the engagements I run, the idea can plainly be built, and the open question is whether it should be.

Key idea 2 of 6

Building got fast, so judgment got expensive

AI is making the production layer of design fast. A competent person can generate interface directions, produce diagrams and create working prototypes at a speed that would have seemed absurd a few years ago.

That does not make the work worthless. It makes it strange to sell it as the production of artifacts. If a prototype that once took two weeks can now be built in two days, the important question becomes: did we prototype the right thing?

The scarce part shifted toward diagnosis, framing, taste and context. Knowing which questions matter. Knowing when an apparently reasonable answer is wrong for this particular organization. Knowing when to stop generating possibilities and commit.

So a prototype should be judged by the quality of the decision it produced, not the speed at which it appeared.

2 days

for a prototype that used to take two weeks

18 days

the voice interface lasted, once a hallway had it

4

image models in the blind pilot, order shuffled, filenames hidden

Key idea 3 of 6

Real code, real inputs, a real Tuesday

Three things separate a prototype that proves something from one that merely exists.

It runs in real code, so the constraints that will decide the product show up now rather than in month four of the build. It runs on real inputs, the messy ones, because a workflow that works on clean sample data has proved nothing about the data people actually have. And it is used by the people who would use the thing on a Tuesday, in the place they would use it, not by the sponsor in a conference room.

The last one is where most prototypes stop short, and it is the one that answers the question.

A prototype has

• Real code, so the constraints show up now rather than in month four
• Real inputs, the messy ones people actually have
• Real users, on a Tuesday, in the place they would use it

A demo has

• The clean sample data from the slide
• The sponsor, in a conference room
• Proof that the idea can be demonstrated

Key idea 4 of 6

A hallway found in eighteen days what no demo would have

I built a training app for our dog, because the professional trainer’s handouts were written for a person sitting still and practice happens in a hallway with a leash in one hand. It is a small product, and every decision on it is mine, which is why it is useful evidence here.

AI built working versions in an afternoon. I judged them. The write-up says which decisions the AI made faster and which it never touched, and the two decisions that mattered most were both made by using the thing rather than by looking at it.

Voice commands lasted eighteen days. The build was fine. The problem was that a handler saying next step brightly at a phone is saying words, in the cue voice, at a dog who is being taught that words in that voice are for her. No demo would have found that. A hallway did, and listening came out.

The illustrations went through a blind pilot: four image models, the order shuffled, the filenames hidden, and two pictures failed and were redrawn until strangers read them right. The first versions looked finished. Finished is not the same as understood.

Key idea 5 of 6

A prototype ends in one of three calls, with the next cost attached

A prototype should end in a call, and there are three honest ones.

Build: it works, people reached for it, and here is what the next step costs. Kill: it did not, and here is what we learned that stops us spending on it again. Park: the idea is sound and the moment is wrong, and here is what would have to change.

1. Buildwhat the next step costs
2. Killwhat stops us spending on it again
3. Parkwhat would have to change

An engagement that talks you out of something expensive has paid for itself. The cheapest product decision a team can make is the one it makes before the build starts, and a working prototype is what makes that decision available.

Key idea 6 of 6

AI is how it gets built, not what it is for

AI is part of how the thing gets built, and sometimes part of what the idea is. It is not what the prototype is for. Where it genuinely helps, you will see it in the build. Where it does not, you will hear that too, because a prototype that flatters the tools that made it has stopped being an instrument and started being a demo again.