build-coded-prototypes

Set fidelity per dimension — visual, content, interaction, data, intelligence — rather than as one dial. Raise a dimension only when the question being answered requires it; for example, voice concepts need high interaction fidelity first while visuals can stay low.

Use the Wizard-of-Oz method: fake the source, never the behavior. Build scripted or browser-based stand-ins behind the exact interface the real layer will use, so upgrading means replacing one function, while state machines and interrupt logic run as real code.

Use one self-contained HTML file with inline CSS and JS when the question is answerable in one screen or flow. Add a zero-dependency Node server only when API keys are needed, and reach for a framework only when the prototype is the seed of the actual product.

Yes, if keys stay server-side behind a proxy and the model returns IDs only while the server renders all displayed values from a verified store. Every dependency needs a deterministic fallback tier so the demo works without keys or network.

Use a terminal-driven logic prototype when the question concerns state transitions, reducers, or data shape rather than appearance. Keep the logic as a pure module behind a thin TUI shell so the validated module can lift directly into production code.

Fold the validated decision into production code properly, write a one-line verdict recording the question and answer, and commit the throwaway artifact to a discard branch. Prototype code lacks tests and error handling, so it should not linger in main.