Apify Opportunity Scout

Design notes for an Actor that scores Actor-build opportunities against demand vs supply across nine sources.

Design notes for apify-opportunity-scout, an Apify Actor that scores a candidate niche for building a new Apify Actor. Submit a plain-language niche description; the Actor runs a four-layer demand framework and a two-axis supply framework across up to nine sources, then asks an LLM to synthesize the verdict (PURSUE / CONSIDER / SKIP) with rationale anchored to the actual data.

The Apify Store page covers the schema, current pricing, and how to try it. This page is for the design questions — why the demand/supply framework looks the way it does, why ethical filters live in the Actor rather than in customer review, and what the verdict deliberately refuses to do.

What this is

Submit a niche description ("BringATrailer auction monitoring", "international Amazon marketplaces", "GitHub repo health scoring"). The Actor walks a pipeline that fetches and aggregates:

• Apify Store supply — every Actor that matches the niche by relevance, with monthly-active-user counts, pricing model, success-rate breakdown, and agentic-payment whitelist status. The top-five table is relevance-ranked, not MAU-ranked — five Actors that actually solve the same problem class beat five Actors that happen to share a keyword.
• Apify Ideas Board — community-submitted ideas matched to the niche by TF-IDF similarity, surfacing demand that hasn’t been built yet.
• Off-platform community demand (standard depth and above) — Hacker News, Reddit, GitHub Issues, Stack Exchange, ProductHunt. Counts plus recent quotes — the quotes matter more than the counts.
• Off-platform commercial competition (deep depth) — G2, Capterra, Crunchbase. If a SaaS catalog already dominates the niche, the buyer audience has routed away from Apify and there’s no opportunity here.
• Ethical filter — separate list of flags (ToS conflicts, KYC ambiguity, scalping risk, scam risk) so they surface before you build, not after.

Output is one dataset record per run plus a Markdown report at OUTPUT.md in the run’s Key-Value Store. The dataset record carries the verdict, scores (demand-side, supply-on-platform, supply-off-platform, routability factor), top-five competitors, demand quotes per source, and a pricing recommendation anchored to the existing competitor distribution.

Why this exists

Most Apify builders pick niches the way you pick a new project on a Friday afternoon: “this sounds cool.” The Apify Store has roughly ten thousand Actors and the Ideas Board exposes another five hundred-plus open ideas; the obvious niches are already built, half-built, or have been tried and abandoned. Picking by gut wastes the week.

The Actor turns “should I build this?” from a hunch into a thirty-second data pull. It can’t tell you whether you specifically should build something — but it can tell you whether a market exists, what shape the existing supply has, and what to charge if you go ahead.

Why the verdict is a tri-state, not a score

PURSUE / CONSIDER / SKIP is the verdict; underneath it sit four numeric scores (opportunity, demand_score, supply_on_platform_score, supply_off_platform_score). The tri-state is the recommendation, the numbers are the explanation.

A single number is the wrong shape here. A 0.7 opportunity score on a niche with strong demand and saturated supply is a different decision than 0.7 on a niche with thin demand and zero supply — same number, opposite move. The tri-state forces the LLM to commit to the actual recommendation given the score combination. CONSIDER is genuinely “I think there’s something here, but I’d need to look closer”, not “the math came out in the middle.” The verdict rationale paragraph is supposed to be readable on its own.

How the four demand layers compose

Demand is structured into four layers, each surfacing different evidence:

• Intent layer — what people have said they want: Apify Ideas Board entries, HN posts and comments, GitHub Issues raising the use case as a gap.
• Revealed demand layer — what people are currently doing: Reddit threads, Stack Exchange questions.
• (Standard depth and up) Off-platform community demand — ProductHunt launches, Reddit subreddit traffic, Stack Exchange tags.
• (Deep depth) Off-platform commercial demand — SaaS catalog presence on G2 / Capterra, Crunchbase funding flags.

Each layer feeds a count plus the actual quote or excerpt that matched. The LLM scoring call sees the counts but is also asked to weight quote quality — five GitHub Issues all asking the same specific question are stronger evidence than fifty Reddit comments that share a keyword.

Why supply has two axes

supply_on_platform_score and supply_off_platform_score are scored separately because they mean different things. On-platform supply is direct competition — other Apify Actors solving the same problem, ranked by MAU. Off-platform supply is buyer-routing risk — if a SaaS already exists outside Apify with mindshare in the niche, the buyer audience has already routed away from “look on the Apify Store” as their first move.

A niche can have low on-platform supply (no Apify competition) but high off-platform supply (G2 reviews of a dominant SaaS player). That combination usually scores low overall because the customer would never think to look on Apify. The two-axis framing surfaces this directly instead of averaging it into a single misleading number.

How the routability factor multiplies in

After demand and supply, the LLM produces a routability object: a buyer_persona (developer / SMB / enterprise / consumer), a factor between roughly 0.05 and 0.80, and a one-paragraph rationale explaining whether the buyer audience is reachable via Apify’s available distribution channels.

Routability is what kills otherwise-promising niches. A niche with strong demand and weak supply but a buyer persona of “non-technical SMB marketing manager” routes badly — they don’t browse the Apify Store, they don’t call MCP tools, and the agentic-payment rails don’t reach them. The factor multiplies into the overall opportunity score; a 0.10 routability factor cuts the score by ninety percent even if everything else is strong.

This is the layer most likely to surprise. Niches that should be opportunities — by demand/supply math — often aren’t, because nobody’s going to find the Actor when they need it.

Why the ethical filter is a hard list, not a score

ethical_filter_flags is an array of categorical flags (tos-conflict, kyc-ambiguity, scalping-risk, scam-risk) rather than a numeric “ethics score.” Ethics in this domain isn’t a sliding dial — either the niche violates a target site’s terms of service or it doesn’t; either the buyer is using the data for fraud-adjacent purposes or they aren’t.

The Actor refuses to build the value distinction into a number because reducing “this looks like fraud enablement” to “0.3” is the kind of optimization that gets you sued. The flags surface as a list; you read the list, and you decide. If any flag fires, the verdict will not be PURSUE regardless of how strong the demand/supply math looks.

Why depth modes exist (and when to pay for them)

Run quick first to triage a backlog. Promote to deep only for niches whose quick or standard verdict was promising and which warrant the higher cost. The price step between tiers reflects real cost — deep does ten-times the per-source scraping plus a more capable analytical pass.

How it compares to alternatives

You don’t get hidden data — the Actor reads the same public APIs and pages you would. It’s the synthesis that’s hard to do by hand: pulling demand and supply signals from eight or nine sources, weighting them against each other, and committing to a verdict in seconds.

Pricing model

Pay-per-event. Each successful run fires one depth-tier charge — quick / standard / deep — that covers the data scraping plus the LLM scoring call for that depth. The platform-managed apify-actor-start event fires once per run at the platform minimum, so per-run overhead is effectively zero.

Failed runs (input validation, malformed niche) don’t fire the depth-tier charge. Per-source data-collection failures don’t fail the run — they degrade silently and add an entry to the warnings array so you know which sources contributed less than expected.

For current per-event rates and any active subscriber discounts, see the Pricing tab on the Apify Store page.

Open questions / future work

• Multi-niche comparison mode. Currently one niche per run. A future variant could take an array of niches and rank them against each other in one call — cheaper than running several separate audits and diffing offline.
• Persistent niche memory. Each run is independent. A “have I already evaluated this niche?” pass that surfaces prior verdicts would help portfolio sweeps but requires deciding where the state lives (KVS? user-supplied dataset? external store?).
• Subreddit-set tuning. The Reddit pull defaults to a small set of generalist subreddits plus LLM-suggested niche-specific ones. The default set is reasonable for developer-audience niches and weak for non-developer ones; configurable per-call.
• Off-platform commercial catalog coverage. G2 / Capterra / Crunchbase covers most of the SaaS supply landscape but not all of it. SimilarTech and BuiltWith would extend visibility into self-hosted competition; cost is the gating factor.
• Tighter routability rubric. Routability is the most useful signal and also the most LLM-judgment-heavy. A more structured rubric — channel-by-channel reachability checks rather than a single factor — would make the score more reproducible without sacrificing the narrative rationale.