Competitive Analysis

---
name: competitive-analysis
description: "Research how 2–4 mature competitors solve a specific business problem (billing, RBAC, search, onboarding, multi-tenancy, etc.) and produce a side-by-side comparison so the team can pick the right approach for their context. Uses web search + scraping; cites every source."
argument-hint: "<feature or problem to research>"
---

# /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):

| Domain | Suggested competitors |
|---|---|
| **SaaS billing & dunning** | Stripe, Recurly, Chargebee, Paddle |
| **B2B SaaS workspace + RBAC** | Linear, Notion, Slack, Asana |
| **CRM** | Salesforce, HubSpot, Pipedrive, Close |
| **E-commerce checkout** | Shopify, Stripe Checkout, BigCommerce, WooCommerce |
| **Marketplace fees + payouts** | Stripe Connect, Airbnb, Etsy, Uber |
| **Customer support** | Intercom, Zendesk, HelpScout, Front |
| **Project management** | Linear, Jira, Asana, Monday |
| **ERP financials** | NetSuite, SAP, Odoo, Microsoft Dynamics |
| **Inventory** | Shopify, NetSuite, Cin7, Brightpearl |
| **Auth / SSO** | Auth0, Clerk, WorkOS, Okta |
| **Notifications / engagement** | Customer.io, Braze, Iterable, Knock |
| **Webhooks / events** | Stripe, GitHub, Segment |
| **Analytics** | Mixpanel, Amplitude, PostHog, Segment |
| **Search** | Algolia, Elasticsearch, Typesense, Meilisearch |
| **Status / incidents** | StatusPage, Statuspal, Better Uptime |

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

| Dimension | Stripe Smart Retries | Recurly | Chargebee | Paddle |
|---|---|---|---|---|
| Retry count | 4 (default) | configurable 1–5 | configurable 1–10 | 3 |
| Retry window | 15 days | 21 days | configurable | 14 days |
| Retry timing | ML-optimized | fixed cadence | fixed/custom | fixed |
| Email cadence | day 1, 3, 7 | day 1, 5, 10, 15 | per template | day 1, 7 |
| Grace period | bills marked past_due | suspend after final retry | configurable | suspend |
| Customer self-rescue | `customer_portal` | hosted page | hosted page | hosted page |
| Card update prompt | yes, in-product | yes, hosted | yes | yes |
| 3DS / SCA handling | re-auth at retry | re-auth at retry | re-auth at retry | re-auth |

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