Develop Spike Summary

<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->

Spike Summary

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

When NOT to Use

• You are recording the resulting architecture decision itself -> use develop-adr; the spike informs, the ADR decides
• The exploration was user research, not technical or design feasibility -> use discover-interview-synthesis
• You want to propose the solution the spike pointed to -> use develop-solution-brief
• The spike has not happened yet: this skill documents results; time-box and run the exploration first

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 Format

Use the template in references/TEMPLATE.md to structure the output. A complete spike summary fills every template section: Overview; Background; Approach; Findings; Recommendation; Artifacts; Open Questions; and Follow-up Items.

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

Examples

See references/EXAMPLE.md for a completed example.

develop-spike-summary - Version History

2.1.0 (2026-06-10)

Quality-convergence minor (F-12 Batch 2): added a "When NOT to Use" section with boundary pointers to neighboring skills, and the Output Format now enumerates the template sections a complete artifact fills. No template or example changes.

2.0.0 (2026-01-26)

Baseline row for the prior published version; see git history for its changes.

Spike Summary: Payment Processor Evaluation

Overview

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

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

Spike Summary: [Spike Title]

Overview

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 -->

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 -->