The prototype that keeps the right to be disliked

The first-week prototype is not a small version of the product. It is an instrument for finding out whether the problem is where everybody thinks it is, while the cost of being wrong is still a week. That purpose sets its shape more than any feature list does.

The five minimum conditions

1. It runs on the customer's real data. An end-to-end loop, however narrow. Synthetic samples and de-identified extracts do not count toward qualification, because the part that breaks in production is almost always the data.
2. It contains at least one observable failure path. Logs, tracing and a user-visible error message, all three. A prototype that cannot fail visibly can only be judged on whether it looks finished.
3. It covers the top-priority metric from the metric table. One metric, the locked row, not a dashboard of plausible ones.
4. It annotates its own unknowns. A README or a one-page risk list naming what is not built, what is assumed about the data and what would break first.
5. It leaves the customer the right to dislike it, at no cost and with no argument.

The fifth condition is the load-bearing one

Most teams treat the right to be disliked as politeness, and skip it when the week gets tight. It is the condition that gives the other four their meaning. A prototype that declares itself ugly, partial and likely to fail — out loud, to the customer, in the same document that lists the known unknowns — changes what the review is actually about. The question stops being "is this good" and becomes "is this the right problem". At week one, the first question has only one honest answer, and it is no.

The right also has a commercial form. If disliking the prototype costs the customer something — a payment, a public commitment, a favour to a sponsor — the customer will not dislike it. They will go quiet, and the team will read the silence as approval, which is how a prototype that should have redirected the project ends up as the foundation of a build.

What a demo-driven prototype costs

A demo is built to be liked. It optimises for the room, so it hides exactly the two things the prototype exists to expose: where the data breaks, and which step of the workflow people quietly skip. The result is agreement without information.

There are two recorded versions of the failure, and they look different. The first is the demo that was complete but not scoped: it impressed, the conversation moved to the contract, and the demo later entered the annex as the acceptance baseline. That ended well only because the annex was written in the same move; a complete demo without an annex is an implicit promise priced at zero. The second is the proposal-shaped version: a platform offer overturned by a single business interview before any build started, because an early artefact had answered a question nobody had asked.

The engineering version of the same error is mistaking local success for production readiness. In one recorded final QA pass of fifty-seven items, thirty-six passed, eighteen failed and three were skipped; the failures included request-origin rejections that only appear with real authentication. The lesson is not that the build was bad but that the verdict was split: the demo slice could go live, the full version could not. A 200 response proves the system accepted a request. It proves nothing about the action completing or the business endpoint receiving it.

Real data, narrower scope, fixed deadline

Three rules do the scoping work. Real data, no exceptions. Shrink the coverage, not the depth — a prototype that covers a single site properly is worth more than one that skims many. Fix the deadline, because a deadline is what forces the trade-off that an open-ended prototype postpones forever.

Recorded cycles are counted in weeks, not quarters: a five-day format, four weeks at the fastest for a vendor-run deployment, four to eight weeks for another. The five-day format shows the extreme end of the same logic. Day zero is spent choosing one narrow battlefield; day one connects systems and pulls data; days two and three are build time with the customer's engineers sitting alongside; days four and five put the result in front of executives who click it themselves and decide whether to move to commercial. The prototype and the buying decision happen in the same room, which removes the gap where a demo usually substitutes for evidence.

The check before the second week

Before the prototype becomes a plan, confirm all five conditions, then ask one question: could the customer have said no without losing anything? If not, the prototype is a demo, and the week bought a mood rather than information. The next stage's job is to measure what survives, which is what the four-week rule is for; the measure itself comes from the metric table, and the conditions around it come from the five-stage method.