Android market research

Android Market Research

This is stage 1 of the Android app pipeline. It runs before planning. The job is to replace assumptions with evidence: what already exists in this category, what users actually complain about, how these apps make money, and where the opening is. Planning that starts from real market facts produces a far sharper product than planning from a one-sentence hunch.

Pipeline position:

> RESEARCH >  planning  ->  monetization  ->  (replan)  ->  design  ->  MCP code  ->  polish

Stage 0 - right-size before you research

Before any searching, settle one thing: is this a quick/personal/throwaway build, or a product the user actually intends to ship? Ask if it is not obvious. The answer sets the depth of everything downstream:

• Quick / personal / utility: do a 5-10 minute pass - name 2-3 obvious incumbents and the one gap, skip sizing, ASO, and most of the brief. Do not spin a throwaway timer into a commercial product. Hand off a one-paragraph brief and move on.
• Real / shippable: run the full flow below.

Most over-scoping starts right here: an open prompt like "make a timer" is not permission to plan a startup. When in doubt, ask.

Core philosophy

1. Evidence over intuition. Every claim in the brief should trace to something observed - an app on the store, a review, a pricing page, a search result. Don't invent market sizes.
2. Competitors are free product research. For almost any idea, 3-7 apps already live in roughly that space. Study them. Steal what works, flip what's stale, attack what users hate.
3. Reviews are the gap map. One- and two-star reviews of incumbents are where unmet needs hide. "I wish it could..." and "it keeps..." are gold.
4. Research is scoped, not infinite. Aim for a tight, decision-useful brief, not a literature review. Stop when the picture is clear enough to plan against.

When this triggers

• "Build me an X app" -> research first, then hand to planning.
• "I have an idea for..." -> research.
• "Is there a market for..." / "who are the competitors for..." -> research, and you may stop at the brief if that's all they asked.

When NOT to trigger: work on an already-scoped project (bug fixes, a new screen, refactors), or pure design/style tweaks.

The research flow

Use WebSearch and web_fetch. Fan out several searches in parallel rather than one at a time.

1. Name the category and the job. In one line, what is this app and what progress is the user hiring it to make? This frames every search.
2. Find the incumbents - from primary sources, not listicles. Identify 3-7 real apps. Where you have browser tools, open the actual Play Store listing and read the live pricing and a real sample of recent reviews - that is primary evidence. Roundup articles are SEO listicles that cite each other; use them only to find candidates, never as the source of a fact. For each app capture: what it does, install scale / rating if visible, its live monetization, and one strength + one weakness.
3. Mine the complaints - read real review text. Read actual one- and two-star reviews on the live Play listing (use the browser if available), plus Reddit/forum threads, for the top incumbents; quote the real wording where you can. Pull the recurring frustrations - these become the differentiation thesis.
4. Survey monetization norms. What's standard in this category - free+ads, one-time, freemium subscription, IAP? Note typical price points. This pre-loads the monetization stage.
5. Scan the ASO / keyword landscape. What terms would users search? Which are crowded, which look winnable? Note 5-10 candidate keywords.
6. Flag risks. Market saturation, a dominant incumbent, platform/feasibility concerns (AI cost, hardware, fragmentation), or regulatory/compliance overhead (finance, health, kids).

Search breadth by ambition: a simple utility needs a light pass (steps 1-3); a crowded consumer or AI-native category needs the full six.

The research brief (output)

Produce a brief with these sections. Keep it to ~1-2 pages; cite sources inline.

• Category & job - one line each.
• Market snapshot - growing, saturated, or niche, with the evidence. If you cite any size/volume number, make it an explicit order-of-magnitude estimate and state the assumptions (e.g. "~X installs, inferred from rating counts"). Never present an estimate as a measured fact.
• Competitor table - 3-7 apps: what it does - strength - weakness - monetization.
• Unmet needs - the 3-5 recurring complaints / gaps, drawn from reviews.
• Differentiation thesis - the one-sentence opening this product could take.
• Monetization norms - what's standard + typical price points (feeds the monetization skill).
• ASO keywords - 5-10 candidate search terms, flagged crowded vs. winnable.
• Risks - market, feasibility, and compliance flags.
• Sources - linked.

Sources and verification (required). The brief is not finished without a linked Sources section. Tag every factual or quantitative claim [verified] (you opened the live source - link it) or [unverified] (listicle, memory, or estimate). If you could not verify something, say so plainly rather than state it with false confidence - a confident brief with zero citations is exactly the failure to prevent.

Hand-off to planning

After the brief is confirmed, hand to android-product-planning. The brief sharpens the planning questions: the competitor table and unmet-needs list feed the "reference apps" and JTBD steps; the monetization norms pre-load the monetization question; the risks feed the coherence checks and pre-mortem.

If the research shows the idea is already well-served with no clear opening, say so plainly before planning - it's cheaper to learn that here than after five screens are built.

Reference apps will date

Anything found on the store reflects today. Re-run the search rather than trusting a cached memory of a category; rankings, pricing, and feature sets move fast.