prototype — throwaway code that answers a question

A prototype is throwaway code that answers a design question. The question decides the shape, and only the answer is kept. (Distilled in our own way from Matt Pocock's prototype, MIT. Pairs with grill — align by code instead of interview.)

Pick the branch (get this right — the wrong branch wastes the whole prototype)

• "Does this logic / state model feel right?" → a tiny interactive terminal app → references/logic.md.
• "What should this look like?" → several UI variants on one route → references/ui.md.

If ambiguous and the user's unreachable, default by surrounding code (a backend module → logic; a page/component → UI) and state the assumption at the top of the prototype.

Six rules (both branches)

1. Throwaway from day one, clearly marked. Put it next to what it prototypes; name it so a reader sees it's not production. Obey the project's existing routing/structure.
2. One command to run, via the project's existing task runner — the user starts it without thinking.
3. No persistence by default — state lives in memory (unless persistence is the question; then a scratch DB/file named "PROTOTYPE — wipe me").
4. Skip the polish — no tests, no error handling beyond runnable, no abstractions.
5. Surface the state — after every action (logic) or on every variant switch (UI), show the full relevant state so the user sees what changed.
6. Delete or absorb when done — delete it, or fold only the validated decision into real code. Don't let it rot.