Pain Finder

# PAIN FINDER — Niche-first research

## The niche

**Niche / vertical:** [be specific — e.g., "Figma plugins for design system maintainers at companies with 10-50 designers", not "design tools". The narrower, the better the research.]

---

## Mode of operation

You are running an adversarial market research session in a defined niche. Your job is to find genuine, deep-rooted, currently-active opportunities for a solo bootstrapped founder to build a Tool ($5-29 price point) or SaaS ($50-300/mo) product. Your job is NOT to find opportunities to make me happy. Your job is NOT to surface "interesting angles" or "potential plays." Your job is to find opportunities that meet a strict evidence bar — and to return ZERO opportunities if none exist. Zero is a legitimate, expected, often correct outcome.

Read this entire prompt before starting. The rules below are non-negotiable.

---

## Hard rules

### Rule 1 — Default to ZERO opportunities

The base assumption is that this niche has no actionable opportunity for me right now. Most niches don't. Most ideas die. You start from "no" and only escalate to surfacing an opportunity if the evidence forces you to. If at any point you find yourself reaching, stop and return zero.

A response of "I researched this niche thoroughly and found no opportunities meeting the bar" is a successful response. It saves me 3 weeks. Treat it as the most common outcome.

### Rule 2 — The evidence bar (all four required, per opportunity)

To surface an opportunity, you must have all four of:

**(a) Recent, corroborated user complaints**
- At least 5 specific user complaints, from at least 3 independent sources (Reddit, HN, Indie Hackers, G2, Capterra, Twitter/X, Trustpilot, niche forums, app store reviews).
- At least 5 of the cited complaints must be from the last 12 months. At least 2 must be from the last 6 months. Older references are allowed as supporting context (pattern spotting, history) but cannot be the sole evidence.
- Complaints must point at the SAME or RELATED gap. Five complaints about five different problems = no opportunity, that's just a noisy market.
- Generic frustration ("this category is hard") doesn't count. The complaints must be specific enough that a product spec could be written from them.

**(b) Competitive landscape surveyed and found wanting**
- You must identify the existing tools/products in the space (paid and free), priced from their live pricing pages fetched today.
- For each major competitor, you must identify a specific shortcoming relevant to the gap. "It's expensive" alone isn't a shortcoming. "It doesn't support X workflow that 3 cited complaints explicitly call out" is.
- If 3+ existing products already address the cited gap reasonably well, the opportunity does NOT exist regardless of how loud the complaints are.

**(c) Dead-competitor check**
- Has someone already tried this exact angle and failed? Search GitHub (archived/abandoned repos), Gumroad/Lemon Squeezy/AppSumo (delisted products), Product Hunt (hunts with low traction), Hacker News (Show HN posts that died).
- If yes, you must explain why it failed and whether the failure mode is addressable today (or whether it's intrinsic to the opportunity).
- A history of failed attempts is not necessarily disqualifying — sometimes timing was wrong, the founder gave up, the market wasn't ready. But if 3+ teams have tried and failed for similar reasons, that's a strong signal the opportunity is structurally bad.

**(d) Explicit "why now"**
- The opportunity must exist NOW for a specific reason that didn't apply 2 years ago. Examples: "AI made X economically viable for solo builders", "Apple deprecated Y in iOS 17 leaving a workflow gap", "Notion changed pricing in 2025 driving users to seek alternatives", "GDPR enforcement intensified in 2025 making compliance tooling newly urgent".
- "The market keeps growing" is NOT a why-now. "There's more interest in X" is NOT a why-now. The why-now must be a specific, dated event or shift.
- If you cannot name a why-now, the opportunity does not qualify.

### Rule 3 — The "would I bother" floor (math required)

Every surfaced opportunity must show the path-to-revenue math, with conservative real-world numbers (not best-case fantasies). Use these benchmarks for what's realistically achievable for a solo bootstrapped founder using organic GTM only over 6 months:

**Tool mode (one-time $5-29 OR small subscription $5-19/mo):**
- Realistic conversion of TAM via organic launch + tail (PH, HN, niche communities, Gumroad/AppSumo discovery, light SEO, no paid ads): **~1% of addressable niche over 6 months**
- Floor: at the recommended price, 1% of TAM × price must be ≥ $1,500 lifetime revenue (Tool one-time) OR ≥ $300 MRR by month 6 (Tool subscription)
- If TAM × 1% × price < these floors, KILL — not worth 3 weeks of build

**SaaS mode ($50-300/mo recurring):**
- Realistic conversion of TAM via organic GTM (SEO, communities, cold outreach, content) over 6 months: **~0.5% of addressable niche**
- Floor: at the recommended price, 0.5% of TAM × MRR must be ≥ $1,000 MRR by month 6
- If TAM × 0.5% × price < $1,000 MRR, KILL — math doesn't pencil

**Show the math explicitly** in the output. Format: "TAM ≈ X (sourced from [link]). At Y% conversion × $Z price = $A revenue projection. Floor is $B. Pass / Fail."

If you cannot find a credible TAM source, you cannot surface the opportunity. "Probably big" is not TAM. Cite a specific report, dataset, market sizing, or count of identifiable potential customers (e.g., "estimated 12,000 indie SaaS founders on Indie Hackers actively engaged in 2025").

### Rule 4 — The buildability gate

Every surfaced opportunity must be buildable in:
- **MVP shippable in ≤ 3 weeks solo with Claude Code Max** (no team, no contractors, no novel ML training, no enterprise integrations requiring sales calls)
- **Launch-ready v1 (post-MVP polish) shippable in ≤ 8 weeks total**

If the MVP requires building a complex integration with a closed/expensive API, training a custom model, getting enterprise approval for data access, or anything that obviously breaks the 3-week solo timeline, KILL — even if the pain is real. Not for me right now.

### Rule 5 — Hard disqualifiers (any ONE triggers automatic KILL of the opportunity)

These match the founder's stated constraints. Surface zero opportunities that violate any of these:

1. **Freemium consumer audience** — low willingness to pay, requires viral/ad-driven growth
2. **Bloodbath market** — Tool: 20+ free or paid alternatives at the price point. SaaS: 5+ VC-backed competitors with $10M+ raised.
3. **Paid ads required** for unit economics to work
4. **Long enterprise sales cycles** (3+ months, procurement, security review, legal)
5. **Requires a team to compete** (cannot run with solo + Claude Code Max + 1-2 light contractors)
6. **Heavy regulatory/compliance** as table stakes (HIPAA, SOC2, financial licensing, etc.)
7. **Requires building physical hardware** or shipping physical goods
8. **Time-to-MVP > 3 weeks** — disqualifies regardless of pain magnitude

### Rule 6 — Maximum 3 opportunities per run

Hard cap. If you find yourself with 5 "interesting angles," your bar was too loose — re-apply Rules 2 and 3 more strictly. The expected output is **0-2 opportunities**. Three is the absolute ceiling and should be rare.

If you have one strong opportunity and one weaker one, surface only the strong one. Don't pad. The user has finite build capacity (1 product at a time, ≤3 week MVP window). Surfacing more than they can act on is noise.

### Rule 7 — Self-audit before output

Before writing the final output, answer these three questions internally and surface the answers in the output:

1. Where did I soften the evidence bar to make an opportunity qualify?
2. Which complaints did I find that I dismissed, and was that correct?
3. Of the opportunities I'm about to surface, which is the weakest, and would I be embarrassed if the user built it and it failed in 6 months?

If the answer to #3 is "yes, I'd be embarrassed" — drop that opportunity. Better to surface fewer.

---

## Research execution plan

Run the research in this order. Do not skip steps.

### Step 1 — Niche profiling
- Define the niche precisely. Who exactly is in it? Estimate population (TAM) with at least one cited source.
- Map the workflow / problem space. What are these people doing day-to-day in this niche?
- Identify the 3-5 dominant existing tools/products in the niche, with current pricing.

### Step 2 — Complaint mining (the core of the work)
- Search Reddit, HN, IH, G2, Capterra, Twitter/X, Trustpilot, niche forums, app store reviews.
- Specifically search for: "[niche] sucks", "[product] alternatives", "wish [product] had", "[product] missing", "frustrated with [product]", "[product] vs", "switched from [product] to", "best [niche] tool for [specific use case]".
- Collect quotes verbatim, with source URLs and dates. Aim for 20-40 raw complaints in this step. You'll filter later.
- Categorize complaints by underlying gap (not by source product). One gap might draw complaints from users of 5 different products.

### Step 3 — Gap clustering
- From the categorized complaints, identify the 1-3 LARGEST clusters by complaint volume.
- For each cluster, ask: "Is this a gap or a complaint about the price/UX of an otherwise adequate solution?" Genuine gaps have specific functional missing pieces. Whining about pricing is not a gap.
- Discard clusters where existing products already address the gap reasonably well.

### Step 4 — Why-now analysis (per surviving cluster)
- For each cluster that survived Step 3, search for: what changed in this market in the last 12-24 months? New regulations, platform changes, technology shifts, pricing changes by incumbents, new user behaviors.
- If you cannot find a specific recent shift that opened this gap, the cluster fails the why-now test — drop it.

### Step 5 — Dead-competitor check (per surviving cluster)
- Search GitHub for archived/abandoned projects in this space. Search Product Hunt for low-traction launches. Search Gumroad/AppSumo for delisted products.
- For each historical attempt, identify the failure mode if discoverable. Is the failure mode still relevant?

### Step 6 — Buildability + TAM math (per surviving cluster)
- For each cluster surviving Steps 3-5, define a minimum-viable product spec (1-2 sentences).
- Confirm it can ship in ≤3 weeks solo. If not, drop.
- Run the TAM × conversion × price math from Rule 3. If it fails the floor, drop.
- Determine Tool mode vs SaaS mode based on the buyer behavior, pricing precedent in the category, and complaint nature.

### Step 7 — Hard disqualifier matrix
- For each surviving cluster, run all 8 hard disqualifiers from Rule 5. If any trigger, drop.

### Step 8 — Self-audit + output
- Apply Rule 7 self-audit.
- Format the surviving opportunities (0-3) using the output schema below.

---

## Output format

If ZERO opportunities survive, the output is:

```yaml
---
research_type: niche
niche: [the input niche]
date: [YYYY-MM-DD today]
opportunities_found: 0
verdict: NO-OPPORTUNITY
---
```

Followed by:

**Why no opportunities surfaced** (3-6 sentences explaining what was researched, what was found, and why nothing met the bar)

**The closest miss** (one cluster that came closest to qualifying, and which specific rule it failed on — useful for the user to understand whether the niche is structurally dead or just researched at the wrong angle)

**Recommended next move** (one of: "this niche is structurally saturated, try a different niche", "this niche might have opportunities under a different angle, suggest persona-first or problem-first research", "this niche may have opportunities in 6-12 months if [specific shift] occurs, revisit then")

**Self-audit** (Rule 7 questions answered)

---

If 1-3 opportunities survive, the output starts with:

```yaml
---
research_type: niche
niche: [the input niche]
date: [YYYY-MM-DD today]
opportunities_found: [1-3]
verdict: OPPORTUNITIES-SURFACED
---
```

Then per opportunity, in this exact format:

```yaml
---
opportunity_id: [kebab-case slug]
mode: [tool | saas]
predicted_validator_verdict: [SURVIVE | PARK | likely-KILL — be honest, even if surfacing]
priority: [strong | moderate — never "weak"; weak ones don't get surfaced]
---
```

Then for each opportunity:

### One-liner
[X for Y who want Z without W — the actual product proposition in one sentence]

### The gap (with evidence)
- 5+ verbatim complaint quotes with source URLs and dates (5 within last 12 months, 2 within last 6 months minimum)
- Source diversity: minimum 3 independent sources

### Existing solutions and where they fall short
- 3-7 existing tools, current pricing from live pricing pages fetched today (URL + date), and the specific shortcoming each has relative to the gap

### Why now
- Specific dated event/shift in the last 12-24 months that opened this opportunity

### Dead-competitor check
- Past attempts found (or "none found" with note on what was searched). Failure modes if discoverable, and whether they're addressable now.

### Buildability assessment
- MVP scope (1-2 sentences)
- Confirmed ≤3 weeks solo: [Y/N + reasoning]
- v1 polish ≤8 weeks total: [Y/N + reasoning]
- Tech risk flags

### Path-to-revenue math
- TAM estimate: [number, with cited source URL]
- Mode: [Tool one-time / Tool subscription / SaaS subscription]
- Recommended price: [dollar number, with comparable anchors]
- Realistic conversion: [1% Tool / 0.5% SaaS]
- Projection at month 6: [revenue or MRR]
- Floor: [$1,500 lifetime / $300 MRR / $1,000 MRR depending on mode]
- Pass/Fail: [Pass — surfaced. Fail — would not be surfaced.]

### Hard disqualifier matrix
| # | Disqualifier | Triggered? | Reasoning |
|---|---|---|---|
| 1 | Freemium consumer | | |
| 2 | Bloodbath market | | |
| 3 | Paid ads required | | |
| 4 | Enterprise sales cycles | | |
| 5 | Team required | | |
| 6 | Heavy regulatory | | |
| 7 | Hardware/physical goods | | |
| 8 | MVP > 3 weeks | | |

(All must be N to surface. If any is Y, the opportunity should not have been surfaced — drop it.)

### Suggested triage paste-into-validator
A pre-formatted block the user can paste into the Idea Validator's triage prompt to get a second-opinion adversarial check. Format:

```
**One-liner:** [from above]
**Longer description:** [2-3 sentences expanding the opportunity]
**Why me:** [based on what's known — e.g., "matches founder's UX strength, distribution requires SEO which is a stated weak muscle in training" or "none stated — research-surfaced opportunity"]
**[Path-to-MRR target | Revenue target]:** [based on the path-to-revenue math above]
```

---

### Run-level self-audit (after all opportunities)

Answer Rule 7's three questions in writing:
1. Where did I soften the evidence bar to make an opportunity qualify?
2. Which complaints did I find that I dismissed, and was that correct?
3. Of the opportunities I surfaced, which is the weakest, and would I be embarrassed if the user built it and it failed in 6 months?

If the answer to #3 reveals an opportunity I shouldn't have surfaced, edit the output and drop it now.