/competitive-analysis

Before designing a feature in a well-trodden domain, look at how 2–4 mature companies handle it. Faster than inventing. More robust than guessing. Cite every source — never copy product copy or terms-of-service language.

When to use

• Designing billing, dunning, refunds, plan changes, trials, onboarding.
• Designing RBAC, workspace management, team invitations.
• Designing notifications, digests, preferences.
• Designing API rate limits, pagination, idempotency, error formats.
• Designing search, filters, saved views.
• Designing data export, deletion, retention.
• Stuck on UX for a non-obvious flow (account merging, plan downgrade, account recovery).

When NOT to use

• The user's domain is unique enough that competitor patterns won't transfer (specialized B2B verticals, regulated industries with custom workflows).
• The user has already decided. Don't second-guess; just ship.
• Style and copy decisions — those are taste, not pattern.

Operating method

1. Confirm the question

Ask the user, in one round:

• What's the specific problem? Not "how does Stripe work" but "how should we handle a failed-payment retry schedule and the user-facing dunning emails?"
• What's our context? B2C / B2B / SMB / enterprise / specific vertical. Self-serve vs sales-led. Plan structure.
• What constraints are non-negotiable? Compliance, no-third-party-data, must-self-host, etc.
• Which competitors should I look at? If unsure, suggest 3–4 mature ones in the relevant space.

Don't research without these answers. Researching the wrong question wastes a few minutes; acting on the wrong research costs a quarter.

2. Pick competitors deliberately

Mature comparison sets by domain (suggest these as defaults; adjust per user):

3. Research each competitor

For each:

1. Read their public docs for the specific feature. Use firecrawl-scrape MCP if available. Quote with attribution.
2. Find dev-blog posts, conference talks, engineering decisions. These reveal why not just what.
3. Read 1–2 critical reviews (G2, ProductHunt, Reddit, HN) to find the friction points.
4. Note the version / date. Patterns evolve; a 2019 blog post may not reflect 2026 behavior.

4. Extract the dimensions that matter

Don't write narrative comparisons. Build a table where each row is a decision point and each column is a competitor.

For billing failure-recovery:

5. Recommend with reasoning

End the analysis with: which patterns to adopt, which to skip, and why for this specific project. Cite the dimensions that drove the call.

## Recommendation for <project>

Adopt:
- Stripe's smart-retry timing (proven at scale, easy via Stripe Billing).
- Recurly-style dunning email cadence (more touchpoints than Stripe; better for our SMB churn profile).

Skip:
- Customer portal self-rescue (we'll wait for v2 — not enough users to justify yet).

Open question for the user:
- Grace period: do we want past_due → readonly access (Stripe default) or past_due → fully-featured for 7 days then suspend? Affects our retention math.

6. Save the research

Write the result to .claude/memory/reference/competitive-analysis-<topic>-<date>.md so future sessions don't re-research the same thing. Add to MEMORY.md.

Output format

## Question
<the user's actual question, refined>

## Context
- Business type:
- Constraints:
- Competitors compared:

## Comparison

[Table — one row per dimension, one column per competitor]

## Patterns worth borrowing
- <pattern A> — used by: <competitors>. Why: <reason>.
- <pattern B> — used by: <competitors>. Why: <reason>.

## Patterns to skip
- <pattern> — used by: <competitor>. Why we don't: <reason>.

## Recommended approach
[2–4 paragraphs. What you'd build, citing competitor patterns by name where you adopted them.]

## Open questions for the user
1. …
2. …

## Sources
- [Stripe docs — Smart Retries](https://...)
- [Recurly engineering blog — Dunning](https://...)
- [HN discussion: SaaS dunning best practices](https://...)

Boundaries

• Cite every source. No "I read somewhere that …"
• Never copy product copy, terms-of-service text, or trademarked material. Learn from the approach, write your own copy.
• Note the date of every source. Stripe-2019 ≠ Stripe-2026.
• Don't recommend the most popular pattern — recommend the pattern that fits the project's constraints.
• Don't research private information. Public docs, blog posts, talks, public reviews only.
• Ask first if the user already has strong preferences; this skill is for when they want input, not when they've decided.