spike

Run a spike: decompose the idea into 2-5 feasibility questions framed as Given/When/Then, order them by risk, build a minimal throwaway prototype for each, and record a verdict. The spike answers whether the approach works before you invest in production code.

A spike is a disposable experiment that answers a specific feasibility question with observable evidence. It follows a decompose, research, build, verdict loop and ends with a VALIDATED, PARTIAL, or INVALIDATED result, after which the code is thrown away.

Build comparison spikes with a shared number and letter suffixes, such as 002a and 002b, testing each approach against the same question. Finish with a head-to-head table covering quality, setup complexity, and performance, then declare a winner for your use case.

Skip spiking when the answer is knowable from documentation or reading existing code, when the work is on the production path and needs real planning, or when the idea is already validated. Spikes exist only for questions research cannot answer.

A good spike produces observable output the user can interact with, such as a runnable CLI, a minimal HTML page, or a single-endpoint server. Hardcode configuration, avoid build tools and Docker, and test edge cases rather than declaring success after one happy-path run.