prototype

Build a small terminal app where the state logic lives in a pure reducer or state machine module with no I/O, and a thin TUI shell renders the current state and keyboard shortcuts each tick. Drive it by hand through edge cases, then lift the validated module into the real codebase.

Render each variant as a separate exported component on the same route, gated by a ?variant= URL search param. Add a floating bottom bar with arrows that cycles variants via the router, so each option is shareable and reload-stable.

No. Prototypes should keep state in memory unless the question being answered is specifically about persistence. If a database is required, use a scratch database or local file clearly marked as disposable.

Use a logic prototype when the question is whether a state model or data shape behaves correctly under real cases. Use a UI prototype when the question is what a page or component should look like, comparing structurally different layouts.

Prototype code skips tests, error handling, and abstractions by design, so it must never ship directly to production. Once it answers its question, either delete it or rewrite the validated decision properly in the real module.