Apify Opportunity Radar — Build / Watch / Reject

Stop spending development time on Actor ideas that already have strong competition, weak pain evidence, or no repeat-use case.

v0.2 automated mode

The recommended mode now accepts a keyword or a public Apify Store Actor URL and queries the public Apify Store API directly. No API token or LLM is required.

For each target it:

• searches relevance-sorted Store results;
• detects likely direct competitors conservatively from core terms in Actor title/name (repo is normalized to repository);
• reads Store metrics such as total users, 7/30/90-day users, total runs, 30-day run counts, review count/rating, bookmarks and last-run time;
• converts those signals into an explainable adoptionEvidence score;
• estimates saturation from competitor count, active competitors and strongest competitor adoption;
• returns PASS, WATCH or REJECT with the observed evidence and reason.

Example automated input:

{
  "targets": [
    { "name": "GitHub Repository Monitor", "keyword": "github repository monitor" },
    { "actorUrl": "https://apify.com/apify/web-scraper" }
  ],
  "searchLimit": 20,
  "strictCompetitionGate": true
}

actorUrl analysis treats the referenced Actor as demand evidence and excludes that exact Actor from the direct-competitor count.

What it does

Submit 1–20 Apify Actor opportunities and score each one on five practical signals:

• pain evidence — is there a clear recurring user problem?
• repeat use — would users run this more than once?
• MVP simplicity — can the useful version stay narrow and cheap?
• differentiation — does the output or workflow materially differ from existing Actors?
• direct competition — how many Apify Store products already solve substantially the same problem?

The Actor returns one decision per candidate:

• PASS — worth building a smallest testable MVP
• WATCH — keep the idea, but collect stronger evidence first
• REJECT — do not spend build time unless the evidence changes

Why this is different

This is not a general market-research scraper. The first version is deliberately a decision layer used before development. Its job is to kill duplicate or weak Actor ideas early.

The strict competition gate rejects crowded copies even when their total numeric score looks acceptable.

Recommended workflow

1. Enter a precise keyword or public Apify Store Actor URL.
2. Run the Radar; it fetches Store evidence automatically and scores adoption/saturation.
3. Inspect the returned direct competitors and evidence, especially when the Store search reports possible truncation.
4. Build only a small differentiated MVP for PASS; research WATCH; normally drop REJECT.
5. If needed, use legacy candidates input to preserve the v0.1 manual scoring workflow.

Example candidates

The included smoke test demonstrates three real decision patterns from the product factory:

• Chrome Extension Ownership Change Monitor — candidate for PASS when no direct change-monitor competitor is found.
• WordPress Plugin Supply-chain Drift — WATCH when demand is real but adjacent monitoring competition already exists.
• GitHub Actions Tag Drift — REJECT when direct Apify security monitors already overlap heavily.

These example inputs are evidence snapshots, not permanently true market claims. Re-check the Store before using them as current facts.

v0.2 scope

Included:

• keyword or public Store Actor URL input;
• public /v2/store lookup with no token;
• direct-competitor filtering from Store search results;
• adoption evidence from users, runs, ratings/reviews and recency;
• saturation scoring;
• explicit sampling fields: observedDirectCompetitors, searchSampleSize, and possibleTruncation so sampled observations are not presented as exact market totals;
• explainable PASS / WATCH / REJECT decisions;
• legacy v0.1 manual mode compatibility;
• no LLM and no paid external API.

Current limits:

• Store search is bounded to 1–50 results per target. observedDirectCompetitors means direct competitors observed inside searchSampleSize, while possibleTruncation=true warns that more Store matches existed beyond the sample;
• direct-competitor matching is deterministic token overlap, not semantic LLM judgment;
• the score measures observed Apify-side adoption and competition, not revenue or guaranteed demand;
• external GitHub/web/news/MCP demand evidence is not fetched yet.

v0.1 compatibility

Included:

• 1–20 candidates per run
• deterministic scoring
• conservative competition gate
• Dataset decision rows
• JSON summary in OUTPUT
• no external API key

The legacy v0.1 manual path itself does not do these automatically:

• Apify Store search (v0.2 automated mode now does this)
• web/news crawling
• revenue prediction
• automatic product creation
• LLM-generated market claims

Those should only be added after the decision model proves useful in real product-factory runs.