A spike is not a proof of concept
Discovery and consulting still blur two different tools. Someone says "we will spike it" and means a two-week sandbox that grows a UI. Someone else says "we ran a PoC" and means they read the vendor docs and liked the demo. A spike is a short investigation that produces a recommendation under a clock. A proof of concept is a narrow implementation that proves or kills a specific technical claim. Mixing the labels does not make the work faster. It makes the next estimate argue with the wrong artifact.
Different questions, different outputs
A spike asks what we do not know yet: which webhook fields actually arrive under retry, whether the OCR provider returns field grounding for this invoice family, how the CMS preview token behaves across environments. The useful output is knowledge — notes, measurements, a recommendation, sometimes a throwaway script — delivered inside a time box.
A proof of concept asks whether a chosen approach can work under constraints you name up front: can PrintNode accept this print path with the client's real job payload; can the field app sync offline edits without double-writing; can the agent refuse when the rulebook citation is missing. The useful output is runnable evidence someone can replay, not a slide that says "looks promising."
We already treat a clickable prototype as comprehension, not feasibility. The same discipline applies here. A spike that never touches the system is research wearing an engineering word. A PoC that never states the claim it is proving is a prototype wearing a risk word.
Time boxes and throwaways are not optional
A spike without an end date becomes a soft project. The clock is the feature: two days to compare two payment providers against the client's actual refund path; half a day to confirm whether Sanity Content Releases can stage the campaign without a redeploy. When the clock stops, you write what you learned and what you still do not know — then you decide.
Spike code is disposable by default. If the investigation produces something you want to keep, that is a separate decision with a separate review, not an accident of the branch surviving. We have watched "spike branches" absorb product polish because nobody wrote that the repo was throwaway.
A PoC can also be disposable, but it must be specific enough to fail. Name the constraint that would kill it: latency above X on a real partner sandbox, duplicate delivery without an idempotency key, a schema that cannot express the content model. Without kill criteria, the PoC drifts into the same inertia we warn about when prototypes lack a written stop signal.
Where teams blur the labels
The common consulting failure is scheduling a "spike" that is really an unscoped build: new screens, a half-integrated vendor, and a demo date. Stakeholders hear investigation; the calendar hears delivery. When the demo looks unfinished, the team climbs fidelity instead of answering the original question.
The other failure is calling a vendor bake-off slide deck a PoC. Reading a feature matrix is useful. It is not proof. We already refuse to treat checklists as bake-offs; the same rule applies to proofs of concept. Touch the client's content, payloads, devices, or failure modes, or do not claim proof.
Spikes feed decisions. PoCs feed the decision with evidence when the uncertainty is material — partner behaviour, ordering, duplicate risk, offline sync. An Architecture Decision Record that cites "we spiked it" without saying what was measured is still improvising. An ADR that cites a PoC without the constraints that were tested is citing a demo.
How we choose in an engagement
If the unknown is "which options are even real," start with a spike. Time-box it inside scoping when the seam is the project — the same habit as spiking the integration before the schedule hardens. Leave with a recommendation, rejected paths, and open risks named as risks.
If the unknown is "will this specific approach hold under our constraints," run a PoC. Keep the surface narrow. Prefer the client's real data over synthetic happy paths. Write the pass/fail line before the first commit, then treat a keep as a deliberate rewrite into the product path — not a quiet promotion of the sandbox.
Announce the label in the room. Clients and studios hear "spike" and "PoC" as interchangeable confidence. Naming which tool you are using, what question it answers, and what artifact they will receive is part of the consulting work. The schedule only stays honest when the words match the evidence.
Questions
- Can a spike include a small coded probe?
- Yes — if the probe exists to answer the question inside the time box and is treated as disposable. The moment the goal becomes "show a working slice," you have crossed into PoC or prototype territory and should name it that way.
- When is a PoC the wrong tool?
- When you still cannot name the claim or the constraints. Proving an unnamed idea produces a sandbox that looks busy and still leaves the decision open. Spike the options first, then PoC the winner you are willing to kill.
- How does this relate to ADRs?
- A spike often fills the options-considered section. A PoC supplies evidence for the choice. Neither replaces Status: Accepted with an owner and a revisit trigger. Proposed ADRs that cite unfinished spikes are still drafts.
Sources
- SSW Rules — Spike vs PoC — Short investigation vs feasibility demonstration; different purpose, timeframe, and outcome.
- Spike first, ADR second — Time-boxed spikes reduce uncertainty; ADRs preserve the accepted trade-offs.
- Related: Spike the seam before you schedule the build
- Related: A proposed ADR is not a decision