| name | validate-idea |
| description | Run a structured validation research sprint on a product or SaaS idea. Uses Hacker News, Indie Hackers, Product Hunt, YouTube comments, competitor review mining (G2, Capterra), and web search to detect real market signals and produce a GO/PIVOT/NO-GO verdict. Trigger whenever a user says "validate this idea", "is there a market for X", "I'm thinking of building Y", "research this idea", "should I build this", "does anyone want X", or any time someone wants to know if an idea is worth pursuing before building it. Always use this skill — do not do ad-hoc idea research without it. |
Validate Idea — First Dollar Sprint Research Skill
This skill runs a structured validation sprint on a product idea before any building begins. The goal is to find signals that a real group of people share a specific problem and would pay to solve it, or to discover early that they don't.
The research is done entirely through public online signals — forums, review sites, and community posts. You are looking for patterns across strangers. One data point is noise. Five threads that sound the same is a market.
What to do first
Ask the user for:
- The idea — what does it do, for whom
- The target audience — who specifically (job title, use case, context, not "small business owners" but "solo consultants who invoice clients monthly")
- The problem it solves — in plain language
If the user hasn't provided all three, ask before proceeding. The quality of your search queries depends entirely on this.
Research phases
Run all five phases. Do not skip any. Do not summarize early.
Phase 1: Community signal research
Search across four platforms where founders, indie hackers, and solo builders talk candidly about tools and problems. For each platform, run at least 2 searches with different keyword angles: the problem itself, the workaround or tool they currently use, and the frustration with existing solutions.
Hacker News
Use the Algolia search API: https://hn.algolia.com/api/v1/search?query=[keyword]&tags=comment,story — fetch this URL via mcp__workspace__web_fetch. Run searches for the core problem and for specific tool names. "Ask HN" threads are especially valuable. Extract: post or comment text, points/engagement, link.
Indie Hackers
Fetch https://www.indiehackers.com/search?query=[keyword] and follow promising threads. The audience here maps directly onto the target user for most ideas — solo founders, early SaaS, people building with limited resources. Extract: post text, replies, any tool or price mentions.
Product Hunt
Search for competitor products and fetch their launch discussion pages. Comments on Product Hunt launches capture early reactions, comparisons to alternatives, and "I wish it did X" signals. Use mcp__workspace__web_fetch to fetch the product page and scroll through comments. Also search for the problem space directly to find products you might have missed in Phase 2.
YouTube
Use mcp__youtube__searchVideos to find videos about the problem space, competitor tools, or "alternatives to X". Then use mcp__youtube__getVideoDetails or mcp__youtube__getTranscripts on the most relevant videos to extract comment signal and spoken content. Tutorial videos, comparison videos, and "I switched from X to Y" videos are the most signal-rich. Comments on these videos often contain raw frustration from real users.
Reddit via web search
Use web search with site:reddit.com [keyword] to surface Reddit threads that Google has indexed. This won't cover everything but catches the most-discussed threads. Run 2-3 searches with different keyword angles and fetch the individual thread pages via mcp__workspace__web_fetch to read comments. Note that recent threads may not be indexed yet.
For each signal found across all five platforms, extract:
- The text (verbatim where possible)
- The platform and source (thread title, video title, etc.)
- Engagement indicator (upvotes, likes, comment count) if available
- A direct link
- Signal type (see taxonomy below)
Aim for at least 15 individual signal items across the five platforms before moving on.
Phase 2: Competitor discovery
Use mcp__workspace__web_fetch or web search to find 2-4 tools that already (partially) solve the same problem. Look for:
- Direct competitors (same problem, similar solution)
- Adjacent tools people use as workarounds
- "Alternatives to X" pages that reveal what users actually switch between
For each competitor found, note:
- Tool name and URL
- What it claims to do
- Its pricing model if visible
- Rough market position (enterprise, SMB, solo, etc.)
Phase 3: Competitor review mining
For each competitor found in Phase 2, pull negative and critical reviews from G2 and Capterra using the available Apify actors.
G2: Use actor automation-lab/g2-scraper via mcp__apify__call-actor
- Search by product name
- Focus on 1-3 star reviews
- Extract: review text, rating, "what problems are you solving" field, switching context
Capterra: Use actor dionysus_way/capterra-reviews via mcp__apify__call-actor
- Focus on cons sections and negative reviews
- Extract: verbatim cons, pricing complaints, workaround descriptions
For each review, note:
- Source (G2 / Capterra)
- The specific complaint or frustration (verbatim)
- Whether it mentions price, missing feature, or switching behavior
- A link to the review or product page
If the Apify actors time out or return empty, fall back to fetching the G2 or Capterra product page directly via mcp__workspace__web_fetch and reading visible reviews. Note in your output when you used a fallback.
Phase 4: Willingness-to-pay research
Look specifically for evidence that people in this space already pay for solutions, or would. Signals include:
- Complaints about pricing of existing tools ("too expensive for solo use")
- Mentions of having switched tools to save money
- "Is there a cheaper alternative to X" searches
- Existing paid communities, courses, or tools in the space (even adjacent)
- Job postings or freelance requests related to solving this problem manually
Draw from what was already collected in Phases 1-3 first. Use web search to fill gaps.
Phase 5: Market economics research
This phase assesses whether the market is worth entering from a business standpoint. A real problem with genuine WTP can still be a trap if the unit economics are hostile. Use web search and pricing pages from Phase 2 competitors.
Collect:
- Price range across the space — what does the cheapest tool charge? The most expensive? Is pricing per seat, per month, per usage?
- Who pays — individuals, small teams, SMBs, or enterprise? This determines price ceiling. Consumer tools rarely exceed $10/month. B2B tools can charge 5-10x more for the same functionality.
- Competition density — how many tools exist? Are they fragmented (many small players, no dominant winner) or consolidated (one or two dominant tools everyone uses)?
- Price ladder gaps — is there a segment underserved by price? (e.g. "everything in this space starts at $50/month but the audience skews solo operators")
- Volume math — at a realistic price point for this audience, how many paying customers to reach €5,000/month? State the math plainly: "at €29/month, that's 173 customers."
- Market structure signals — look for evidence of whether this is a winner-takes-most market (switching costs are high, people don't compare tools) or a fragmented one (lots of tools coexist, users switch regularly).
Signal taxonomy
Use this taxonomy when classifying each signal you find. Tag every item in your signal log.
Strong signals (PASS):
- Names a specific tool and complains about it ("HoneyBook doesn't let me…")
- Describes a workaround they built or currently use ("I just export to CSV and manually…")
- Mentions price or budget ("$49/month is insane for what it does")
- Asks where to find something that should exist ("Is there anything that does X without requiring Y?")
- Uses emotional language about a specific failure ("I lost a client because of this")
Weak signals (FAIL — do not count these):
- "I'd use that" with no mention of current pain
- "Someone should build this" with no evidence they currently struggle
- Agreement without specifics ("Yeah totally, this is a problem")
- Feature requests with no expressed frustration at alternatives
The goal is to find PASS signals. If you find mostly FAIL signals, that is itself a signal — and likely a NO-GO or PIVOT.
Output format
After completing all five research phases, produce a structured report. Use this exact format — no markdown headers other than the ones specified, no bullet soup, write in clear sentences where possible.
Audience definition
Who you are validating for. One tightly scoped paragraph. Should include: who they are, what context they're in, what they're currently doing to solve this problem (even if imperfect). Revise this from whatever the user originally said — make it more specific based on what you actually found in the research.
Signal log
A numbered list of individual signals found. For each:
[N] TYPE: PASS or FAIL
Source: Hacker News / Indie Hackers / Product Hunt / YouTube / Reddit / G2 / Capterra / Web
Signal type: [workaround / price complaint / tool frustration / "does X exist" / emotional language / weak agreement / etc.]
Quote: "verbatim text or close paraphrase"
Link: URL or thread reference
Include all signals found, both PASS and FAIL. Do not filter at this stage.
Competitor map
A short table or list showing:
- Tool name
- What it does
- Price range
- Main frustration from reviews
- Switching context (do users leave it? where do they go?)
Pattern summary
2-4 paragraphs synthesizing what the research actually showed. What is the recurring frustration? What words do people keep using? Where does the pain live in the workflow? What do existing tools get wrong that your idea could get right?
Do not make this promotional. Just describe what you found as clearly as possible.
Willingness-to-pay signals
Specific evidence that people in this space pay for things. List concrete examples — tools they pay for, amounts mentioned, switching behavior, manual workarounds they pay for with time. If you found nothing, say so plainly.
Market economics
A short, plain assessment of the business viability of this space. Cover:
- What existing tools charge (price floor and ceiling, billing model)
- Who the paying customer actually is — individual, team, or company — and what that means for the price ceiling
- How many competing tools exist and whether the market is fragmented or dominated
- Whether there is a visible gap in the price ladder
- The volume math: at a realistic price point for this audience, how many customers to reach €5k/month? State the number.
- A one-sentence market structure read: is this a space where a new entrant can get traction, or is it winner-takes-most with entrenched habits?
Do not inflate or soften this section. If the unit economics are hostile, say so.
Verdict
One of: GO / PIVOT / NO-GO
GO — at least 8 PASS signals from at least 2 different platforms, clear pattern of shared frustration, at least one WTP signal, competitors exist but have a clear gap, and the market economics support a solo or small-team business (volume math is achievable, price ceiling is meaningful, market is not locked up by a dominant player).
PIVOT — some signal present but not consistent, or the audience is wrong, or the frustration exists but existing solutions are good enough, or the market economics make it viable only at scale a solo founder can't reach. Explain specifically what to pivot toward.
NO-GO — signals are weak, mostly FAIL, no WTP evidence, or the problem only exists for a tiny fringe, or the economics require competing on volume in a saturated market with a sub-€10/month price ceiling. Explain clearly and don't soften it.
After the verdict, write 2-3 sentences on the single most important thing the research showed — the insight that should drive next steps.
Important notes
Always cite your sources. Every signal in the log needs a link or reference. The user should be able to click through and verify.
Do not invent signals. If you cannot find enough data, say so and explain what searches you ran and what turned up empty. A "we found very little" result is itself valid research output.
Do not editorialize during the research phases. Collect first, synthesize in the pattern summary.
Keep your language plain. No "exciting opportunity", no "significant pain point", no significance inflation. Describe what you found. The verdict speaks for itself.
