A spike solution is a short, throwaway experiment written to explore a technical question or reduce uncertainty. The name comes from Extreme programming: Kent Beck used “spike” to mean driving something sharply through a problem to understand it, the way you drive a spike through wood to test the material.

A spike is written to answer a specific question, not to be production code. Examples:

• “Can we call this third-party API with the response time we need?”
• “How difficult would it be to port this module from C to Rust?”
• “Which JSON parsing library handles these edge cases correctly?”

The output of a spike is knowledge, not code. The spike code is typically discarded after the question is answered. If you keep spike code and build on top of it, you end up with production code that was written under the wrong constraints — speed of exploration rather than correctness and maintainability.

Spikes are time-boxed. A spike that runs for three days without a clear answer is a project, not a spike. The time box forces a conclusion: either the question is answered, or the spike reveals that the question was the wrong question to ask.

In agile planning, spikes appear as backlog items: “Spike: evaluate database options for time-series storage, 1 day.” The deliverable is a brief written recommendation, not a feature.