A fake door is not a prototype
Fake-door tests are having another moment — pretotyping, painted doors, "validate demand before you code." They answer a real question: will anyone reach for this. They do not answer the questions that killed or kept RuleCaddie, Veto, and Private Reserve. A click is not a citation path, a secrecy model, or a product seam. Treat a fake door as demand smoke. Treat a prototype as evidence about the risky part.
Curiosity is a cheap signal
A fake door puts a control in a real UI — a tab, a pricing tier, a "try AI summary" button — and measures who reaches for it. That is useful. People will say yes in a survey for things they will never open. A click costs them something small, and that cost filters out pure politeness.
It is still a cheap signal. The person who taps "Rules assistant" on a golf app might be bored in a cart, hunting for settings, or reacting to a label that sounded clever. Curiosity, confusion, and intent collapse into one event. If your dashboard only counts that event, you will hear a story about demand that the data cannot actually tell.
We use the door when the open question is reach: does anyone look for this entry point at all. We do not use it when the open question is whether the product can be honest under load — wrong golf rulings, leaked vetoes, a club room that needs a different permission model than a personal log.
What a prototype has to prove
RuleCaddie's early bet was not whether golfers would tap a rules button. It was whether an answer could be forced to cite a real Rules of Golf number, and whether the product should refuse when it could not. No painted door produces that evidence. You need retrieval against the actual rulebook, a fixed set of course situations, and a clear fail when the citation path lies.
Veto's bet was secrecy as the mechanic. If another player's veto can be reconstructed from what the client receives, the game is already broken. That is a Postgres and realtime-publication question. A "Start a round" control with a waitlist behind it tells you people want the social shape. It tells you nothing about whether the secret stays in the database.
Private Reserve had a different failure mode: two products sharing a logo. A palate log and a private club room look related on a landing page. They diverge the moment permissions, audience, and retention paths show up. A fake door can measure interest in the brand. Only a narrow prototype — or a deliberate split — shows whether they are one build.
When a door earns its keep
Use a fake door when the risky assumption is desire for an entry point you have not built, and when a wrong yes is cheap to reverse. Discrete, nameable features fit: a new export, a second catalog tab, a concierge add-on that users already understand from the label.
Even then, do not stop at the first click. Require a second, slightly expensive step — a waitlist email, a one-line use-case, a booking for a walkthrough. The drop between click and that step is usually where curiosity falls away. Write the thresholds before you ship the door, the same way we write kill criteria before the first commit: keep/kill numbers decided while you are still allowed to be wrong.
Timebox it. An indefinite painted door trains people that your product lies, and the metric drifts as the surrounding UI changes. One to a few weeks, a named cohort, then remove the control. The door is an experiment fixture, not a permanent "coming soon" wing of the app.
Do not promote a CTR into a roadmap
The failure mode we see is narrative laundering. A four-percent click rate becomes "validated demand," which becomes a sprint, which becomes a half-built feature that still has not touched the hard part. The door answered "will they reach." The team heard "should we ship."
Keep the outputs in different buckets. Door results update a demand note: who clicked, who completed the second step, what they said they expected. Prototype results update a decision note: keep, kill, or narrow the question. Mixing those documents is how a curiosity spike funds three months of architecture.
If vibe-coding makes a thin vertical slice cheap, prefer that over a door when the risk is technical or domain-honest. A weekend against real rules text, real RLS, or a real offline package beats a month of interpreting button analytics. Use the door when building even a dishonest slice would teach you the wrong lesson — when the lesson you need is whether anyone bothers to look.
Match the instrument to the question
Before we open a prototype repo, the brief still wants four lines: the one question, the kill criteria, throwaway-or-grow, and the smallest artifact that can produce the signal. A fake door can be that artifact — but only when the question is about reach. When the question is about correctness, secrecy, offline honesty, or whether two ideas are one product, the door is the wrong instrument.
RuleCaddie, Veto, and Private Reserve each needed a different fidelity because each bet failed in a different place. Matching fidelity to the failure mode is the craft. A painted control is high fidelity for attention and low fidelity for almost everything else.
So call the door what it is. It is pretotyping for demand smoke. It is not a prototype, not a keep, and not permission to skip the hard proof. When the smoke clears, you still owe the real question a real instrument — and a written signal for when to stop.