prototype

You can validate a state machine design by building a throwaway logic prototype that tests specific edge cases and surfaces the full relevant state after each action without requiring persistence or tests.

Exploring UI variations involves generating multiple radically different UI structures for the same route in a throwaway prototype, allowing you to compare designs visually before production work begins.

To pressure-test an API shape, build an in-memory logic prototype that runs with one command, validates the data model, and reports the state after each step to answer uncertain design questions.

Yes, design validation prototypes are throwaway and in-memory by default, satisfying one-command runnability without requiring database persistence, heavy polish, or test coverage to validate uncertain business logic.

After testing state transitions, you should follow a clean capture-or-delete process by recording the final answer in durable notes like NOTES.md, an ADR, or an issue, then discarding the throwaway prototype.

You should avoid using throwaway prototypes when your design questions are already certain or when you need permanent, polished production code, as prototypes intentionally skip persistence, tests, and heavy architecture.