Origin: Extreme Programming, time-boxed
The term "spike" comes from Extreme Programming (XP), where it describes a short technical investigation separate from delivery work — a quick escalation on a specific question, not a product increment.
The difference from a normal task is in the objective. A sprint task produces code that ships to production. A spike produces knowledge: the answer to a question that, without it, would leave the next technical decision resting on opinion instead of evidence. Code written during a spike is disposable by definition — it exists to answer the question, not to last.
The second defining characteristic of a spike is the time-box. It doesn't end when it's "done"; it ends when the time runs out, with or without a definitive answer. This is deliberate: the alternative — investigating until you feel confident — tends to expand to fill whatever time is available, and library or architecture decisions rarely have a natural point of "enough information." The time-box forces an exit: by the end of the allotted time, either there's enough to decide, or there's enough to know that the next step is a smaller, more specific spike.
When a spike is worth doing
Not every technical decision needs a spike. It's worth opening one when three conditions show up together.
First, there's a real choice between concrete options — swapping a state management library, adopting a new ORM, deciding between two authentication approaches — not a preference already settled within the team. If the answer is obvious to whoever will implement it, the spike is theater.
Second, the uncertainty is about behavior, not syntax. Reading an API's documentation resolves syntax questions. A spike exists for what the documentation doesn't answer: how the library behaves under the project's real conditions, how it interacts with the rest of the stack, what trade-off only shows up after someone actually tries to integrate it — a debt of uncertainty that only clears when the decision is tested, not just discussed.
Third, the cost of being wrong is high enough to justify the time the spike takes. Swapping a small, isolated dependency rarely justifies a formal spike; swapping the data layer or the UI framework does — reverting later is expensive, and the spike is comparatively cheap.
When these three conditions line up, the most common pattern is the spike as a PoC before commitment: a minimal prototype, written to be thrown away, that exercises the point of greatest uncertainty — not the full happy path, just the part nobody can answer without running code.
What a good spike produces
A poorly run spike produces a feeling — "I think option A is better." A good spike produces an artifact that anyone on the team, including someone who didn't participate, can read and use to decide. Three elements tend to be present.
Options compared on the same criteria. There's no point testing option A thoroughly and only reading option B's documentation — the comparison is only as good as what was verified under the same conditions: setup, learning curve, package size, ecosystem maturity, or whatever is relevant to that specific decision.
A recommendation, not a neutral list. The spike exists to decide, so it needs to end with a position — "I recommend option A, because X" — even if the honest answer is "neither solves it, the problem is somewhere else." A list of pros and cons without a conclusion just pushes the decision back to whoever was supposed to receive it already made.
A PoC or next-steps plan. If the spike didn't exhaust the question in the available time — the most common case —, it needs to make explicit what's left to verify and how, so the next step picks up where the spike left off, not from zero.
It's also worth noting what a spike is not. It's not market research into which tool is "the most popular" — popularity isn't the criterion, fit for the project is. And it's not an open-ended evaluation without a deadline: a spike without a time-box just becomes another backlog item that never closes, because there's always one more question to clarify before the decision.
Where SpikeMe fits in
SpikeMe exists to help organize that output. You point it at your project's package.json, describe the topic of the decision, and the tool generates a structured spike document — compared options, a recommendation and a PoC plan — from the real context of your stack, not a generic template. The work of investigating is still yours: SpikeMe organizes the result so it becomes a recorded, reviewable, shareable decision, instead of a conclusion lost in a chat thread. To generate a spike from your project, see spikeme.io.