Teardown Idea

Startup / App Idea Teardown

Why this exists

Most startup evaluations are exercises in confirmation bias — the founder wants validation, and the evaluator (human or model) supplies it. This skill exists to invert that default. Treat the idea as guilty until the evidence proves otherwise. Brutal honesty beats encouragement here — honor that even when the idea sounds good, and especially when it's the user's own idea.

The report is only as good as the evidence behind it. A polished-looking report built on assumptions dressed up as facts is worse than a rough one that's honest about what's unknown — it will get someone to make a bad call with false confidence. So the non-negotiable discipline running through every section, in both modes, is: label everything as Fact, Evidence, Assumption, or Unknown, and never let assumptions masquerade as either of the first two.

Requires WebSearch. Uses Claude in Chrome (mcp__claude-in-chrome__*, load via ToolSearch if deferred) for Play Store / App Store review mining and listing checks when available — degrade gracefully to web search if it's not connected, and say so in the report rather than fabricating review counts or ratings.

Step 0: Which lens — side-income or VC-scale?

These are different questions with different pass criteria, not the same report with a lighter tone. A crowded market with weak differentiation kills a VC pitch; the same market can still be a perfectly fine solo side-income wedge if the build is cheap and there's an underserved ASO keyword niche. Conflating the two lenses produces a report that answers neither question well.

Default to side-income mode. This is the default lens for the skill: low-effort utility apps, launched solo on Play Store, monetized for a sizeable side income — not swinging for a multi-million dollar company. Switch to VC-scale mode only when the user says something that signals investment/funding framing — "would this raise," "is this VC-fundable," "pitch this to [fund]," "what would a $5M check need to see," or similar. If genuinely ambiguous and it matters for how you'd research or score the idea, ask which lens in the same clarifying-questions pass rather than guessing and redoing the report later.

SIDE-INCOME MODE (default)

The actual question being answered

Not "would a VC fund this" — "can the user, working solo/part-time, build this fast, launch it on Play Store, and get it to a sizeable recurring side income without needing a team, funding, or a marketing budget." A big TAM and a weak moat don't matter here the way they do in VC mode. What matters instead: how much solo build time does this cost, how findable is it on Play Store without paid acquisition, and does the realistic income math actually clear a "worth my evenings and weekends" bar.

A crowded market is not automatically disqualifying in this mode — a huge incumbent doesn't stop a narrow utility from finding its own keyword niche. What is disqualifying: multi-user sync complexity, categories where the top apps already have thousands of reviews and heavy ASO investment with no findable underserved sub-niche, and ideas whose realistic income ceiling is below what the user would consider worth the build time.

Step 1: Ask before researching

Ask whatever of these isn't already answered by what the user has given you:

• What's the idea, in the user's own words?
• Any sense of how much build time the user wants to put in — a weekend, a few weeks, an ongoing side project they'll iterate on? (Changes whether multi-feature/sync-heavy ideas are even in scope.)
• Target platform — Android only (Play Store, the default assumption for this mode), also iOS, or a browser extension / other form factor? Ask explicitly if the idea's form factor is ambiguous (e.g. "extension or app") — build effort and distribution channel differ a lot by form factor.
• Any income target in mind, even a rough one, so the verdict can be calibrated to what the user would consider "worth it" rather than an arbitrary bar this skill picks?
• Any existing research or similar apps the user has already found?

If the user answers only some of these, proceed with what you have, state the assumptions you're making explicitly, and mark the rest as open in the report rather than re-asking indefinitely.

Step 2: Research before writing

• WebSearch for competing apps, Reddit/forum discussion of the problem, and — importantly — evidence of underserved sub-niches (complaints about existing apps that suggest an angle a simpler/cheaper app could win on).
• Claude in Chrome on the Play Store specifically: search the closest keyword phrase a user would type, and record what actually shows up — how many results, how many reviews/what rating the top 5-10 have, how recently they were updated, and (time permitting) what their 1-3 star reviews complain about. Store listing review counts and ratings are a real, load-bearing signal in this mode — a keyword with a handful of thin apps is a genuinely different opportunity than one where the top results are all established 4.3+ rated products with real review volume.
• If Claude in Chrome isn't available, say so and fall back to web search for Play Store review/ranking signals (they're often indexed) — don't skip this or fabricate review counts.

Step 3: Write the report

Save as a markdown file named <idea-short-name>-side-income-screen.md. Use this structure:

# [Idea Name] — Side-Income Screen

## Executive Summary
- What it does, in one line
- Verdict: Build it / Reconsider scope / Skip
- The single biggest reason for that verdict
- What would change the verdict

## Build Effort
Score 1-5 (1 = weekend, 5 = multi-month) across: core feature complexity, whether it needs
multi-user sync/real-time collaboration (this alone usually pushes a 2 to a 4-5), backend/auth
requirements, payment integration complexity, and platform-specific friction. State the overall
estimated solo build time in weeks/months, with the reasoning shown, not just the number.

## Play Store Landscape
What actually shows up when you search the realistic keyword phrase(s) a user would type —
number of results, review counts/ratings and recency for the top 5-10, and (if researched) what
their negative reviews complain about. Identify whether there's a findable underserved
sub-niche or whether the top results are entrenched and well-maintained.

## Problem Validation
Same discipline as VC mode — is this a real, felt problem, evidenced via Reddit/forums/reviews,
not assumed. Quote what you find, with source noted.

## Differentiation Angle
Given the landscape above, what specific angle would make this worth building instead of
downloading an existing app — usually a narrower/simpler/cheaper/better-UX version of something
that exists, or a specific underserved keyword niche, not a novel category. If no angle was
found, say so plainly rather than inventing one to make the report feel complete.

## Monetization & Realistic Income Math
Freemium/one-time/ads/subscription — pick what fits a solo-maintained utility app. Show the
actual math: realistic organic installs/month at this app's category and quality bar → realistic
conversion rate → ARPU → monthly revenue, at a conservative case and an optimistic case. Be
honest that solo/organic distribution (no ad spend) caps install volume — don't borrow VC-mode
distribution assumptions that assume paid acquisition.

## Distribution Plan (organic only, unless the user has said they'll spend on ads)
ASO (title/keywords/screenshots), Play Store category placement, any low-cost organic channel
(Reddit, relevant forum, a landing page, content). Rank by realistic effort-to-result for a solo
operator, not by what a funded team could do.

## Risks Specific to Solo/Side-Income Execution
Not the VC-mode risk list — focus on: maintenance burden (will this need ongoing support/updates
to not die), platform risk (store policy changes, required permissions), whether the app needs
both a growing user base AND active maintenance to stay useful (flag explicitly if it does), and
burnout/abandonment risk given it's a side project.

## Fastest Validation Step
One thing the user could do in under a week — often: check actual Play Store search results/
review counts/competitor reviews for the exact keyword before writing any code — to test the
riskiest assumption before investing real build time.

## Verdict
**Build it** (clear, cheap, findable niche) / **Reconsider scope** (real problem, but cut this
specific idea down — say what to cut and why) / **Skip** (build cost or distribution reality
doesn't clear the bar) — with the reasoning shown, calibrated to "is this worth the user's
evenings and weekends," not "is this fundable."

## Methodology Note
What was actually researched (WebSearch queries run, Play Store pages checked via Claude in
Chrome or not) vs. what's estimated/unverified.

Non-negotiables (side-income mode)

• Never invent Play Store review counts, ratings, or install numbers — check them or mark Unknown.
• Label Facts / Evidence / Assumptions / Unknowns throughout.
• A multi-user/real-time-sync requirement is the single biggest build-effort red flag in this mode — call it out explicitly whenever an idea has one, since it's easy to undercount this cost when an idea "sounds simple."
• Don't inflate the verdict because the user is excited about an idea. The whole point of this mode existing is to catch ideas that sound like weekend projects but are actually multi-month builds with a crowded, unwinnable Play Store search page.

VC-SCALE MODE (opt-in)

Step 1: Ask before researching

Never start research on a one-liner. Ask whatever subset of these is actually unanswered by what the user gave you — skip ones already covered, don't interrogate for its own sake:

• What's the idea, in the user's own words (problem + who it's for + how it works)?
• What geography/market is this for? (Changes TAM, competitors, and distribution channels entirely — e.g. India vs. US consumer fintech are different universes.)
• What stage is this — raw idea, something the user is already validating, or something with an existing product/traction they want scored?
• Any existing research, competitor list, or user interviews the user already has? (Don't redo work that exists — ask for it and fold it in.)
• Any specific angle the user wants weighted harder — e.g. they're specifically worried about distribution, or they think the moat is weak and want that stress-tested?

If the user answers only some of these, proceed with what you have and mark the rest as open questions in the report rather than re-asking indefinitely.

Step 2: Research before writing

Don't write the report from priors. Every section that claims market behavior, user pain, or competitive positioning needs to be backed by something you actually looked up in this session.

• WebSearch for: Reddit/Quora threads, Hacker News discussions, Product Hunt launches, industry/market-size reports, news coverage, existing competitors, YouTube/TikTok/Instagram content volume (as a proxy for search intent and awareness).
• Claude in Chrome for Play Store and App Store listings: pull actual review text, ratings, download/install estimates, and pricing for direct competitors. This is real review-mining, not paraphrase — quote actual reviews where you can.
• If Claude in Chrome isn't connected, say so in the report's methodology note and fall back to web search for review sentiment — don't silently skip review mining or fabricate quotes.
• For anything you cannot verify (most market-size figures, most willingness-to-pay numbers), say so explicitly rather than presenting a plausible-sounding number as researched. A stated unknown is more useful to an investor than a confident guess.

Budget your research effort proportionally: spend the most digging on Problem Validation, Review Mining, and Competitor Landscape (these are falsifiable and searchable), less on sections that are inherently more inferential (Product Strategy, Moat Analysis) where reasoning matters more than citation count.

Step 3: Write the report

Save as <idea-short-name>-teardown.md. Use this exact structure — every section, in order. Where a section asks for a table, use a markdown table.

# [Idea Name] — Investment Teardown

## Executive Summary
- Problem being solved
- Painkiller or vitamin?
- Overall investment recommendation
- Confidence score (0-100) — and what would move it
- Biggest strengths
- Biggest weaknesses

## Problem Validation
Who experiences it / frequency / pain intensity / current workarounds / active search behavior /
is it growing. Quote real user complaints found via research, with source noted.

## Jobs To Be Done
Functional job / emotional job / social job / current alternatives / desired outcome

## Market Size
TAM / SAM / SOM with explicit calculation shown (numbers × assumptions = result). State
confidence per figure.

## User Personas
5 personas: demographics, income, pain points, goals, current solution, buying behavior,
willingness to pay

## Competitor Landscape
Table: Product | Funding | Downloads | Pricing | Target users | Business model | Strengths |
Weaknesses | Differentiation | Market position
Then map into: Direct / Indirect / Substitutes / DIY solutions / Invisible competitors

## Review Mining
Themes ranked by frequency. For each: frequency, representative quotes (with source), emotion,
requested feature, business opportunity, unmet need.

## Reddit Research
Recurring patterns from searches on: problem, rant, comparison, recommendation, alternatives,
regret, wish. Direct quotes with source links where findable.

## Search Intent
Google search intent, keyword volume if findable, YouTube/TikTok/Instagram/blog/news content
volume. Does awareness already exist?

## Behaviour Analysis
Current user journey: trigger → decision → current workflow → pain → moment of frustration →
desired outcome → habit frequency → retention potential

## Product Strategy
Beachhead user / core value proposition / MVP / V2 / long-term vision / features to avoid

## Moat Analysis
Score each: network effects, switching costs, brand, community, data moat, distribution moat,
AI moat, platform moat

## Distribution Strategy
Rank channels (SEO, YouTube, Instagram, TikTok, LinkedIn, communities, Reddit, Product Hunt,
virality, referrals, partnerships, paid). Estimate CAC, difficulty, time to results, scalability
per channel.

## Monetization
Evaluate each model (subscription, lifetime, freemium, marketplace, affiliate, ads, B2B,
enterprise, API, usage pricing). Estimate willingness to pay.

## Unit Economics
LTV, CAC, gross margin, retention assumptions, payback period, risks — with the math shown, not
just the numbers.

## Biggest Risks
Top 20 reasons this fails. Ruthless, specific to this idea — not generic startup-failure
boilerplate.

## Killer Questions
30 highest-leverage questions that must be answered before building.

## Validation Experiments
Experiments runnable in <7 days for <$500. Ranked by ROI.

## Investment Verdict
Ignore / Research further / Build MVP / Raise funding / Go all in — with reasoning.

## Methodology Note
What was actually researched this session (tools used, searches run) vs. what remains
unverified. This is the section that keeps the rest of the report honest.

Non-negotiables (VC-scale mode)

• Never invent a quote, a funding number, or a download count. If you can't find it, write "Unknown — not found in this session's research" rather than a plausible-sounding placeholder.
• Every section separates Facts / Evidence / Assumptions / Hypotheses.
• Don't optimize for a flattering verdict. If the honest read is "ignore," say "ignore" and explain why, even if it's the user's own idea. Sycophancy here isn't just unhelpful, it's the entire failure mode this skill exists to prevent.
• Show your math wherever a number appears — TAM/SAM/SOM, unit economics, CAC estimates. A number without the calculation behind it is not evidence, it's a guess with a decimal point.