spike

Technical Spike SOP

A spike is a time-boxed investigation that answers a specific technical question. It produces a recommendation and confidence level — not production code.

When to Use

• A key technical assumption has never been tested
• Two or more approaches look viable but their trade-offs are unclear
• A third-party library or API needs to be evaluated before committing to it
• Performance characteristics of an approach are unknown
• Team estimate variance for a task is high (disagreement signals hidden uncertainty)
• User says "I'm not sure if X is possible" or "I need to investigate Y"

---

The Spike Process

1. QUESTION  →  2. TIME-BOX  →  3. INVESTIGATE  →  4. DOCUMENT  →  5. DECIDE

---

Phase 1 — Frame the Question

A good spike question is:

• Specific: answerable with yes/no or a concrete recommendation
• Bounded: does not expand into full implementation
• Actionable: the answer changes what you build next

Good spike questions:

• "Can we use Postgres full-text search for our query patterns, or do we need Elasticsearch?"
• "Does the Stripe Connect API support split payments with our required fee model?"
• "Can the existing auth middleware handle WebSocket connections, or does it need changes?"
• "Will SQLite handle the concurrent write volume our gateway requires?"

Bad spike questions (too vague):

• "How should we build the payment system?" → This is planning, not a spike
• "Is React a good framework?" → Too broad, not actionable

Fill in before starting:

## Spike: [Short descriptive title]

**Question to answer:** [Single specific question]
**Why this matters:** [What decision does the answer unlock?]
**Time box:** [1h / 2h / 4h / 8h — pick one]
**Definition of done:** [What output proves the question is answered?]

---

Phase 2 — Time-Box Rules

Investigation depth	Appropriate time box
Read docs + quick prototype	1–2 hours
Build minimal proof-of-concept	4 hours
Benchmark two approaches	4–8 hours
Evaluate multiple vendors	8 hours max