Prototype or technical spike?

Start with the risk, not the artifact

A polished prototype is wasteful when the real uncertainty is whether the model can produce acceptable behavior with available data. A technical experiment is equally wasteful when nobody agrees on the user decision or experience it should support.

Use a clickable prototype for experience risk

Choose this when workflow, comprehension, control, stakeholder alignment, or usability is uncertain. It should make the critical journey inspectable; it does not need to resemble the entire eventual application.

Use a technical spike for feasibility risk

Choose a bounded experiment when model behavior, latency, cost, data quality, architecture, or integration is the deciding uncertainty. Define representative inputs and acceptance criteria before running it. A spike is evidence, not production code.

Use a workflow model for system risk

Choose this when value or failure travels across users, teams, operational steps, approvals, and connected systems. Map authority, handoffs, failure recovery, and evidence before automating the workflow.

Choose one primary proof

A five-day sprint should not promise every artifact. Select one primary proof, record what remains unknown, and use the result to define the next decision.