Prototyping

A prototype is throwaway code that answers a question. The question decides the shape.

"Build to learn, not to ship."

Pick a branch

Identify which question is being answered — from context, surrounding code, or by asking the user:

• "Does this logic / state model feel right?" → Build a tiny interactive terminal app that pushes the state machine through cases hard to reason about on paper. Surface the state after every action.
• "What should this look like?" → Generate several radically different UI variations on a single route, switchable via a URL search param and a floating bottom bar. Surface state changes on every variant switch.

Getting this wrong wastes the whole prototype. If genuinely ambiguous and user isn't reachable, default to whichever branch better matches the surrounding code (backend module → logic; page/component → UI).

Rules that apply to both

1. Throwaway from day one, clearly marked as such. Locate prototype code close to where it will actually be used (next to the module or page it's prototyping for) so context is obvious — but name it so any reader can see it's a prototype, not production. For UI routes, obey whatever routing convention the project already uses; don't invent new structure.