spike

A spike is a disposable feasibility experiment used to validate a software idea before a production build. You need a spike when you must reduce risk by testing high-uncertainty areas, comparing approaches, or surfacing unknown constraints before committing resources.

To validate a software idea, decompose the concept into 2–5 independent spike questions targeting high-risk areas. Perform targeted research for each question, build minimal interactive prototypes, and issue evidence-backed verdicts to decide whether to proceed, iterate, or abandon the project.

Decompose a feature concept by isolating 2–5 independent feasibility questions that represent what can fail. Each spike question targets a specific unknown constraint, allowing you to perform focused research and build a minimal throwaway prototype for that individual risk.

The best way to compare technical approaches is running a research-then-build workflow. Conduct targeted research to select an approach, build a disposable interactive prototype, and produce evidence-based verdicts with recommendations on what worked, what failed, and surprises encountered.

A feasibility spike should produce clear VALIDATED, PARTIAL, or INVALIDATED verdicts based on observable results. It must document what worked, what didn’t work, surprises discovered during testing, and provide actionable recommendations for the real production build.

Avoid using throwaway prototypes when your concept carries low risk and the feasibility is already understood. Spikes add overhead through decomposition and research, so if unknown constraints and technical uncertainties are minimal, proceeding directly to production development is more efficient.