Nobody wrote a specification for this.
This site, the agent behind it and the deck it links to were all built in one sitting, starting from a voice note. The person steering wrote about two hundred words of direction in total. Almost none of them described what to build.
They described what to stop considering.
Subtract, do not specify
The instinct when briefing anyone, a contractor or a model, is to add: here is what it should do, here is what it should look like, here is the edge case I thought of in the shower. Additions are infinite. They diverge. Twenty requirements produce a thing that satisfies twenty requirements and nobody.
Removals converge. Forget that platform. We are not doing a survey. That hardware question is irrelevant. Each one deleted a branch of the tree, and the remaining space got sharper rather than smaller.
The constraints wrote the best features
This is the part worth stealing, and it was not obvious until afterwards. Every significant improvement in this build arrived disguised as a restriction.
The original plan was to poll colleagues beforehand, collect what they were interested in, and arrive with a populated system. The instruction came back: no poll, it goes in the product.
Read as a scope cut, that is a loss. Read as a design input, it forces every question to be asked at the moment it is needed, which means the thing starts empty, which means it has to be honest about knowing nothing, which means you can ask it the same question twice, four minutes apart, and let the audience produce the difference themselves.
The restriction invented the demo. Nobody would have specified it.
A second one: the machine in the kitchen is irrelevant. That sounds like a question being waved away. What it actually did was force the cup-quality term from something asserted into something measured from real ratings. Which is the only reason the system can say this scored badly, go out instead rather than defending its own conclusion. The thesis became falsifiable because a question was refused.
One gate, where undoing gets expensive
There was exactly one checkpoint in the whole session. Not a review per step, which is just a specification delivered slowly. One, placed immediately before the first decision that would cost days to reverse.
build it, confirm stack first
Four words of process for a day of work. Everything before that point was deliberately cheap: a sentence, a conversation, a page of clickable variants built to be thrown away. Everything after it was expensive, so it waited behind a decision that had actually been made.
Judge it from the chair of the person receiving it
Midway through, a screen came back with this note: this part is too technical, it is not clear where I landed. What is my resolve?
That is not a bug report. The screen in question was accurate and useless: it explained which internal capabilities had been unlocked, written from the point of view of the person who built the capabilities. The person arriving at it had come for a coffee. Rewritten, it says a day, a time, a floor, who is brewing and who is worth talking to.
A correction phrased as a feeling, where did I land, is usually diagnosing a perspective error rather than a wording one.
Then check it, in the place it actually runs
The cheapest way to lose everything the method bought is to finish with should work. Nothing here was reported as working until it had been driven in the environment it runs in: every screen across every state, concurrent writes to see whether any were silently lost, forged credentials to see whether the gate held, and the same checks again against the live URL rather than a local one.
Several things were only true because they were checked. Twenty people submitting at the same instant would have overwritten each other under the obvious data model. A gate screen rendered blank rather than refusing, for a reason invisible from the code. The published deck would have frozen on its first slide, because deleting a button left something pointing at it.
What it does not solve
The method assumes the expensive step can be spotted in advance. Put the gate in the wrong place and you are back to improvising with extra ceremony.
And it needs a counterpart willing to decide. The one answer that breaks it is whatever you think at the gate, which quietly removes the only checkpoint in the process while feeling like trust.
The shape of it
- A thesisOne sentence the thing bets on, with a number you can derive from it. Costs a sentence to be wrong.
- SubtractionOptions presented, options removed. Costs a conversation.
- Disposable prototypesSeveral directions on one page, each stating its cost. Built to be discarded. Costs an hour.
- The gateOne confirmed decision before anything expensive. Costs days.
- Build, then verify where it runsCosts weeks.
The thing this produced is a coffee agent that mostly tells you to stay in the building. Whether that is a good idea is argued over here, with numbers. How it was argued for is the more portable half.