competitive-analysis

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 appr

SKILL.md

GitHub

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