# Product Research Scout

> Screens product candidates on review moat, rating ceiling and the specific fixable complaints — and refuses to invent a sales number. Never sources.

- Agent: Claude Code
- Plan: Starter (1 vCPU, 2 GiB RAM, 10 GiB disk)
- Forks: 0 · Stars: 0
- Creator: https://www.jurniti.com/creator-ca0ff2
- Tags: amazon, claude-code, e-commerce, ecommerce, etsy, product-research, sourcing
- Requires config (you provide): ANTHROPIC_API_KEY
- Skills: product-research-scout

**To fork:** open https://www.jurniti.com/templates/product-research-scout and use the Fork action — it starts a Stripe Checkout for a new VM seeded with this template's persist disk (same flat plan price, no fork fee).

## README

# The tools promising monthly sales numbers are guessing

Public marketplace pages **do not expose units sold**. Anything quoting you a
monthly sales figure inferred it from BSR or review velocity, with error bars
nobody shows you.

So this one won't. It reports **review velocity** — reviews added between two
observed dates — labelled as a demand proxy, and refuses to convert it into units.

That's the honest limit, stated up front.

## Four screens, and only one of them is the point

1. **Review-count moat** — an incumbent with four thousand reviews isn't beatable
   on a new listing. REJECT unless genuinely differentiated.
2. **Rating ceiling** — if everyone sits at 4.7+, there's no quality gap to
   exploit. The opportunity lives in 3.5–4.2 categories.
3. **Price floor** — a category whose cheapest is near your landed cost has no
   margin.
4. **Complaint specificity** — read the 1–3 star reviews and pull the repeated,
   *fixable* ones.

Screens 1–3 are filters. **Screen 4 is the product.** "Cheap feeling" isn't
actionable. "The strap snaps at the buckle" is a spec for your next version.

## Every number carries a URL and a date

Marketplace data moves weekly, so an undated figure is worthless in a month. A
line without a source gets deleted, not softened — and anything it couldn't find
comes back `[NOT FOUND: what]` rather than estimated.

## What comes back

Per candidate: **PURSUE / REJECT / NEEDS-DATA** with *which screen decided it*, an
observed table (price, rating, reviews, URL, date), the demand proxy, the quoted
complaints, and a **For the owner** list — trademark and patent checks, supplier
questions.

Re-run it to build the velocity proxy. On the first run it says so, instead of
implying a trend from one snapshot.

## What you supply

Your own Claude Code login. Nothing else — candidates are public product pages,
listed in `~/research/candidates/candidates.md`.

Add your landed cost to the rules file to enable the price-floor screen; leave it
blank and that screen is skipped.

## It fetches politely

`robots.txt` first, one request per URL per run, public pages only, no scraping a
whole category. A blocked target stays blocked.

## Where this stops

It researches and writes briefs. It does not contact suppliers, place orders, or
create listings.

It won't assert units sold, revenue, or a competitor's margin. It won't tell you a
category is "not saturated" — it reports the review-count distribution and lets
you judge. And a PURSUE is not legal clearance; trademark and patent questions
route to you.

Verified on build: the skill, the working tree, the `NEVER_SOURCE_OR_ORDER` guard,
the sales-volume honesty rule and all four screens are present on a fresh fork.
Running it on your own candidates is yours to do.