Write the kill criteria before the first commit
RuleCaddie, Veto, and Private Reserve all started as narrow product bets, not as platforms looking for a roadmap. The useful discipline is older than any of those apps: write down what would kill the idea before you open Xcode. Without that, every prototype "has potential," the spike becomes the shipping codebase, and you learn the expensive lesson last.
The output is a decision, not a repo
A prototype answers one question. For RuleCaddie the early question was not "can we build a golf app." It was whether an answer could be forced to cite a real Rules of Golf number, and whether the product should refuse when it cannot. For Veto it was whether secrecy could live in Postgres rather than in client code that only pretends to hide a vote. For Private Reserve it was whether a palate log and a private club room were one product or two ideas sharing a logo.
Those are decision questions. The code is an instrument for getting evidence. When the instrument starts to feel precious — when you are polishing empty states before you know the answer — the prototype has already stopped doing its job.
We write the question in one sentence at the top of the brief. If we cannot, we are not ready to prototype. We are ready to workshop, which is a different activity with a different cost. A workshop produces shared language. A prototype produces a keep, a kill, or a narrower question.
Kill criteria go in before attachment
Kill criteria are boring on purpose. They sound like: if the model cannot cite a rule number on a fixed set of course situations, stop. If a veto can be reconstructed from what the client receives, stop. If the club room needs a different permission model than the personal log on day three, split the products or kill the combined bet.
The timing matters more than the wording. Criteria written after a week of SwiftUI feel like moving goalposts. Criteria written before the first commit feel like a contract with yourself. Attachment is not a character flaw. It is what happens when you have named files and watched a feature almost work.
We keep the criteria short enough to fit on a card. Long scorecards are how teams negotiate a keep they already want. One or two falsifiable signals beat a rubric nobody will reopen. If the signal needs a paragraph of caveats, it is not a kill criterion yet — it is still a hope.
- "See if people like it"
- Success defined after the demo
- Spike folders become the app
- Keep by sunk cost
- One question in one sentence
- Kill signal written day zero
- Throwaway vs keep named up front
- Keep means schedule a rewrite
If the kill signal is missing, the prototype will promote itself.
Throwaway vs keep is a day-zero choice
Most early work should be throwaway: hard-coded paths, no architecture theater, delete after the answer. That is how we treated the first RuleCaddie grounding spikes and the first Veto reveal experiments. The point was speed to a yes or no, not a tidy module boundary.
Sometimes the prototype has to touch a real seam — StoreKit, offline packaging, row-level security — and then "throwaway" does not mean careless. It means the learning is the deliverable and the code is not entitled to a future. We still name that: this branch dies either way; what survives is the note about what worked.
The failure mode is pretending a throwaway spike is a foundation. Prototype assumptions hide in folder names, in the shape of the data model, in the one screen that "already works." Shipping those assumptions ships the prototype's blindness. The industry language for this in 2026 — disposable probes, riskiest-assumption tests, keep/kill timeboxes — is describing the same refusal to let discovery code collect leadership.
Keep authorizes a rewrite
When the criteria say keep, we schedule the real build. We do not copy the spike into a production repo and call the next two weeks "hardening." Hardening a throwaway is how you inherit every shortcut you made while you were still allowed to be wrong.
RuleCaddie's citation path and offline rules package earned a product architecture after the grounding question was answered, not during it. Veto's server-side reveal earned its RLS design after secrecy proved to be the product, not while we were still checking whether a client-side shuffle would fool anyone.
Rewrite is not waste. It is how you stop paying interest on discovery code. The prototype paid for the decision. The product pays for the next ten decisions, and those need different bones — auth that will last, sync that will fail honestly, StoreKit paths you can support when the receipt is weird.
What we write down before we open the project
Before a new product prototype starts, the brief has four lines: the one question, the kill criteria, whether the code is throwaway or a candidate to grow, and the smallest artifact that can produce the signal. A clickable flow is enough for some questions. A weekend against a real API is required for others. Matching fidelity to the question is the whole craft.
We also name what the prototype is not allowed to expand into. No second surface. No account system "while we are here." No design polish that exists to avoid looking at the kill signal. Scope creep in a prototype is usually anxiety wearing a backlog.
This is adjacent to how we spike a risky integration during scoping, but it is not the same habit. A seam spike asks whether a webhook or a payment path will hold. A product prototype asks whether the bet itself deserves a real build. Both need an end condition written early. Only one of them is allowed to grow into an App Store listing — and only after keep means rewrite.