---
title: "Spike Summary"
description: "Documents the results of a time-boxed technical or design exploration (spike). Use after completing a spike to capture learnings, findings, and recommendations for the team."
generated: true
source: scripts/generate-skill-pages.py
tags:
  - Develop
  - coordination
---

:::note[Quick facts]
**Phase:** Develop | **Version:** 2.0.0 | **Category:** coordination | **License:** Apache-2.0
:::

**Try it:** `/spike-summary "Your context here"`

A spike summary documents the results of a time-boxed exploration . a focused investigation to reduce uncertainty before committing to implementation. Spikes answer specific questions like "Can we integrate with this API?" or "Is this technology viable for our use case?" The summary captures findings so the team can make informed decisions without the spike participants needing to repeat explanations.

## When to Use

- After completing a time-boxed technical exploration
- When evaluating technology choices or vendor options
- After proof-of-concept work that needs to inform team decisions
- When investigating feasibility of a proposed solution
- Before committing engineering resources to a new approach

## How to Use

Use the `/spike-summary` slash command:

```
/spike-summary "Your context here"
```

Or reference the skill file directly: `skills/develop-spike-summary/SKILL.md`

## Instructions

When asked to document a spike, follow these steps:

1. **State the Question Clearly**
   Articulate the specific question the spike was designed to answer. Good spike questions are focused and answerable with the time-box available. If the question evolved during the spike, document both the original and final versions.

2. **Define the Time-Box**
   Document the time allocated (e.g., 3 days) and actual time spent. If the spike exceeded its time-box, explain why and note any remaining work.

3. **Describe the Approach**
   Explain what was tried, in what order, and why. This helps future readers understand the methodology and whether alternative approaches were considered.

4. **Present Findings with Evidence**
   Document what was learned, supported by concrete evidence . code samples, performance benchmarks, screenshots, or API responses. Distinguish between verified findings and hypotheses that need more testing.

5. **Make a Clear Recommendation**
   Answer the original question directly: proceed, do not proceed, or proceed with conditions. Avoid hedging . the team needs actionable guidance.

6. **Document Artifacts**
   Link to any code, prototypes, diagrams, or documentation created during the spike. These artifacts often have ongoing value beyond the summary.

7. **Capture Open Questions**
   Note what the spike didn't answer and what additional investigation might be needed.

## Output Template

# Spike Summary: [Spike Title]

## Overview

| Field | Value |
|-------|-------|
| **Question to Answer** | [The specific question this spike investigated] |
| **Time-Box** | [Allocated time, e.g., 3 days] |
| **Actual Time Spent** | [Actual time, e.g., 2.5 days] |
| **Spike Lead** | [Name/role] |
| **Date Completed** | [YYYY-MM-DD] |

## Background

<!-- Why was this spike needed? What context is important? -->

[Brief context explaining why this question needed investigation]

## Approach

<!-- What was tried, in what order, and why? -->

### What We Tried

1. [Approach 1: description and rationale]
2. [Approach 2: description and rationale]
3. [Approach 3: description and rationale]

### Technologies/Tools Evaluated

- [Technology/Tool 1]
- [Technology/Tool 2]

## Findings

<!-- What did we learn? Support with evidence. -->

### Finding 1: [Title]

[Description of what was discovered]

**Evidence:**
- [Specific data point, benchmark, or observation]
- [Code sample, API response, or screenshot reference]

### Finding 2: [Title]

[Description of what was discovered]

**Evidence:**
- [Specific data point, benchmark, or observation]

### Finding 3: [Title]

[Description of what was discovered]

**Evidence:**
- [Specific data point, benchmark, or observation]

## Recommendation

<!-- Answer the original question directly. Proceed, don't proceed, or proceed with conditions. -->

**Decision:** [Proceed / Do Not Proceed / Proceed with Conditions]

[Clear rationale for the recommendation, referencing findings above]

### If Proceeding

- [Key consideration or condition 1]
- [Key consideration or condition 2]
- [Estimated effort for implementation]

### If Not Proceeding

- [Why this path is not recommended]
- [Alternative approaches to consider]

## Artifacts

<!-- Links to code, prototypes, diagrams, or documentation created -->

| Artifact | Location | Description |
|----------|----------|-------------|
| [POC Code] | [Link] | [Brief description] |
| [Architecture Diagram] | [Link] | [Brief description] |
| [Vendor Documentation] | [Link] | [Brief description] |

## Open Questions

<!-- What didn't we answer? What needs more investigation? -->

- [ ] [Open question 1]
- [ ] [Open question 2]
- [ ] [Open question 3]

## Follow-up Items

<!-- Next steps if the team decides to proceed -->

| Action | Owner | Timeline |
|--------|-------|----------|
| [Next step 1] | [Who] | [When] |
| [Next step 2] | [Who] | [When] |

## Example Output

<details>
<summary>Spike Summary: Payment Processor Evaluation</summary>

# Spike Summary: Payment Processor Evaluation

## Overview

| Field | Value |
|-------|-------|
| **Question to Answer** | Should we use Stripe or Adyen for payment processing on our new platform? |
| **Time-Box** | 3 days |
| **Actual Time Spent** | 2.5 days |
| **Spike Lead** | Chen Wei, Senior Backend Engineer |
| **Date Completed** | 2026-01-12 |

## Background

Our new e-commerce platform needs payment processing capabilities. We currently process $2M/month through a legacy system and expect to scale to $10M/month within 18 months. The decision between Stripe and Adyen will affect our transaction costs, integration timeline, and ability to expand internationally.

## Approach

### What We Tried

1. **Stripe Sandbox Integration:** Built a complete checkout flow using Stripe Elements. Created test webhooks and simulated various payment scenarios including 3D Secure, declined cards, and refunds.

2. **Adyen Test Integration:** Implemented Adyen's Drop-in Components in a parallel branch. Tested the same scenarios as Stripe for direct comparison.

3. **Fee Analysis:** Modeled transaction costs at current volume ($2M/month) and projected volume ($10M/month) using published pricing and obtained quotes from both vendors.

4. **International Capability Review:** Researched multi-currency support, local payment methods, and regulatory compliance for our target markets (US, EU, UK, Canada).

### Technologies/Tools Evaluated

- Stripe API v2024-12-18, Stripe Elements, Stripe Webhooks
- Adyen API v68, Drop-in Components, Adyen Webhooks
- Both tested with React 18 frontend, Node.js 20 backend

## Findings

### Finding 1: Stripe has significantly better developer experience

Stripe's documentation is more comprehensive and includes more working examples. The sandbox environment required no setup . we were processing test payments within 15 minutes. Adyen required account manager approval and took 2 days to get sandbox access.

**Evidence:**
- Time to first successful test payment: Stripe (15 min), Adyen (2 days including access wait)
- Documentation score (internal rating): Stripe 9/10, Adyen 6/10
- Stack Overflow questions with accepted answers: Stripe (47,000+), Adyen (3,200)

### Finding 2: Adyen has lower fees at scale

At our projected $10M/month volume, Adyen's interchange++ pricing results in meaningful savings. However, at current volume, the difference is marginal.

**Evidence:**
- Current volume ($2M/month): Stripe $58K/year, Adyen $54K/year (7% savings)
- Projected volume ($10M/month): Stripe $290K/year, Adyen $245K/year (16% savings)
- Stripe's 2.9% + $0.30 vs. Adyen's interchange++ (avg 2.4% + $0.20 at volume)

### Finding 3: Both meet international requirements, but Adyen has edge in Europe

Both processors support our target markets. Adyen has more local payment method integrations in Europe (iDEAL, Bancontact, SEPA Direct Debit) which could improve conversion for EU customers.

**Evidence:**
- Local EU payment methods: Stripe (8), Adyen (15)
- Both support Apple Pay, Google Pay, PayPal
- Both are PCI Level 1 compliant

### Finding 4: Stripe's subscription billing is more mature

If we add subscription products in the future, Stripe Billing is significantly more capable than Adyen's recurring payment features. Adyen would require a third-party subscription management tool.

**Evidence:**
- Stripe Billing: Proration, trial periods, usage-based billing, revenue recovery
- Adyen: Basic recurring only, no built-in subscription management

## Recommendation

**Decision:** Proceed with Stripe for MVP, plan migration path to Adyen

### Rationale

Stripe is the right choice for our current stage. The superior developer experience will accelerate our launch timeline by approximately 2-3 weeks. At our current volume, fee differences are minimal ($4K/year). Once we reach $10M/month and validate product-market fit, we should reevaluate migration to Adyen for cost savings.

### If Proceeding

- Use Stripe Elements for checkout (fastest integration)
- Implement webhook handlers for payment lifecycle events
- Estimated integration effort: 2 weeks for full production deployment
- Build payment abstraction layer to facilitate future processor migration

### Migration Trigger

Consider Adyen migration when:
- Monthly transaction volume exceeds $5M consistently for 3 months
- EU revenue exceeds 30% of total (local payment methods become important)
- Fee savings would exceed $50K/year (pays for migration effort)

## Artifacts

| Artifact | Location | Description |
|----------|----------|-------------|
| Stripe POC | /spikes/payment-processor/stripe-poc | Working checkout flow with webhooks |
| Adyen POC | /spikes/payment-processor/adyen-poc | Comparable checkout for benchmarking |
| Fee Model | /spikes/payment-processor/fee-analysis.xlsx | Volume-based fee comparison |
| Architecture Diagram | /spikes/payment-processor/payment-arch.png | Proposed payment system design |

## Open Questions

- [ ] What is the exact timeline for Stripe's pricing negotiation at higher volumes? (Sales said "competitive" but no specifics)
- [ ] How does PSD2 Strong Customer Authentication affect conversion in EU? Need production data.
- [ ] Should we implement payment abstraction from day one or wait until migration is certain?

## Follow-up Items

| Action | Owner | Timeline |
|--------|-------|----------|
| Begin Stripe production integration | Chen Wei | Week of Jan 20 |
| Set up Stripe Radar for fraud prevention | DevOps | Week of Jan 20 |
| Document payment abstraction interface | Chen Wei | Feb 1 |
| Schedule Adyen volume pricing call for Q3 | PM | Q3 2026 |

</details>

## Real-World Examples

See this skill applied to three different product contexts:

<details>
<summary>Storevine (B2B): Storevine B2B ecommerce platform . revenue attribution feasibility spike for Campaigns v1</summary>

**Prompt:**

```
/spike-summary

Spike: Revenue attribution feasibility . can SendGrid open/click webhooks
be linked to Storevine purchase events within v1 timeline?

Context:
- Revenue attribution is a launch-gate requirement (confirmed in interview
  synthesis and opportunity tree)
- Engineering ADR selected SendGrid for Campaigns email delivery
- Engineering Lead asked for a 1-week spike before sprint planning

What we investigated:
- SendGrid Event Webhook payload structure and custom data fields
- Whether Storevine's customer_id can survive the email→purchase journey
- POC: send a test campaign, receive webhook, match to staging order
- Attribution window design: real-time vs. deferred (7-day)

Need: full spike summary with findings, recommendation, and follow-up
items. Will share with PM and Engineering Lead to unblock sprint planning.
```

---

**Output:**

# Spike Summary: Revenue Attribution via SendGrid Event Webhooks

</details>

<details>
<summary>Brainshelf (Consumer): Brainshelf consumer PKM app . topic-matching algorithm spike for the Resurface digest</summary>

**Prompt:**

```
/spike-summary

topic matching spike for resurface. alex spent 3 days on it last
week. question: can we build something that picks saved items relevant
to what the user has been reading recently, accurate enough to not
annoy people?

three approaches tested:
1. tag-based . use OG tags, domain, URL patterns. simplest, no ML.
2. tfidf . extract article text, vectorize, cosine similarity. no
   external api. medium complexity.
3. openai embeddings . text-embedding-3-small. highest accuracy but
   adds external dependency and per-call cost.

benchmark: 3 real user libraries (anonymized), 50 items each,
manually rated as "relevant" or "not relevant" to recent reading.

results: tags = ~55% [fictional], tfidf = ~72% [fictional],
embeddings = ~84% [fictional].

recommendation: go with tfidf for mvp. meets the 70% bar we set,
no external dependency. plan to migrate to embeddings later if the
feature sticks.
```

---

**Output:**

# Spike Summary: Topic-Matching Algorithm for Resurface Digest

</details>

<details>
<summary>Workbench (Enterprise): "Workbench enterprise collaboration platform: CRDT library evaluation for Blueprint co-editing"</summary>

**Prompt:**

```
/spike-summary

Spike: CRDT library evaluation for Blueprints real-time co-editing
Product: Workbench (enterprise collaboration platform)
Engineer: Nate P. (Backend Engineer)
Duration: 5 days (Dec 1-5, 2025)

Background:
- Blueprints requires real-time co-editing (20+ concurrent editors per document [fictional])
- Our editor is ProseMirror-based; no current collaboration layer
- Enterprise requirements: offline-first, conflict resolution, per-user audit trail
- Target: 20+ concurrent editors, <100ms merge latency [fictional]

Libraries evaluated:
1. Yjs (CRDT, MIT) -- y-prosemirror binding; offline-first; sub-document support
2. Automerge (CRDT, MIT) -- Rust/WASM; strong offline; no ProseMirror binding
3. ShareDB (OT, MIT) -- central server model; mature; no offline support

Findings from prototype:
- Yjs: integrated in 2 days; 45ms merge latency at 20 users [fictional]; +38KB gzipped [fictional]; offline works out of box
- Automerge: no ProseMirror binding (3-4 week custom build [fictional]); +120KB gzipped [fictional]; excellent offline
- ShareDB: integrated in 1.5 days; 62ms merge latency [fictional]; +22KB gzipped [fictional]; NO offline (disqualified)

Stakeholders: Karen L. (Eng Lead), James W. (VP Engineering)
```

---

**Output:**

# Spike Summary: CRDT Library Evaluation for Blueprints Co-Editing

</details>

## Quality Checklist

Before finalizing, verify:

- [ ] Original question is clearly stated
- [ ] Time-box is documented (allocated vs. actual)
- [ ] Findings are supported by evidence, not just opinions
- [ ] Recommendation directly answers the question
- [ ] Artifacts (code, diagrams) are linked or attached
- [ ] Open questions identify remaining unknowns

## Output Format

Use the template in `references/TEMPLATE.md` to structure the output.
