I built this for a client who sells on Shopify. It is in daily use: it is what they open before deciding what to stock next.
The problem with asking a model for a product
Ask a language model for a winning product and it will give you a confident answer with invented numbers. The margin will look good because nothing checked it. That is the failure mode of every AI product research tool I have seen, and why most of them cannot be trusted.
So here the model never decides. It proposes.
The working demo of this system opens on a desktop screen. Here is how it works:
How it works
- 01Describe a nichePlain words, any language.
- 02Supplier candidatesDropship ready products with the real cost to land them in your country.
- 03The real market priceeBay listings of the same product, matched by photo rather than by title.
- 04The profit mathsMarket median, minus landed cost, minus the fee.
- 05A clear verdictWorth selling, check first or skip, with the reason in one line.
- 06Who is advertising itA shortcut to the ads already running for that product.
What actually decides
Every candidate is resolved against a supplier API: a real product record, real variants, and a real shipping quote for the destination country and quantity, from which a landed cost is computed. That client is the largest single piece of the project, with token refresh, rate limiting and the per country shipping lookup, because this is the part that has to be right.
A rules layer then runs before any scoring. A candidate that trips an elimination rule is dropped outright with the reason recorded. What survives is scored out of a hundred, and the score carries its justification rather than arriving as a bare number.
Making the market data true
Competition and price figures are worthless if they are averaged across different products, and search results for one item routinely include similar looking things from other sellers. A naive tool averages them together and reports a market that does not exist.
So listing images are fingerprinted and compared perceptually, and a seller only counts toward the competition set once the image confirms it is the same product. Title matching alone fails here, because listings are keyword stuffed and translated inconsistently, which is also why a separate layer holds product name variants across languages.
A ceiling on what it can spend
An agentic research loop calls a model many times and each call costs money. Token usage is costed per call, added to a running total, and checked against a budget before the next step runs. Hitting the ceiling raises a stop rather than quietly continuing.
Without that, the honest instruction to a user is to watch the meter. With it, the tool is safe to hand to someone who will leave it running.
Surviving the providers
Five providers sit behind one interface, including a mock for tests. The unglamorous parts are what keep it running: stripping reasoning blocks out of responses, pulling JSON out of prose, and repairing JSON a model truncated mid structure rather than discarding the response and paying for another call.
There is also a command that pulls the provider's current model list, ranks it, tests the top three with real requests and writes the winner into config. Providers retire models without warning, and this is what makes the tool repair itself instead of failing quietly.
Three ways in, and a build for non developers
The same engine is reachable from a browser panel, a terminal chat and a Telegram bot, and it ships as a double click Windows application as well. The people who need this analysis are shop owners, not engineers, so the install step was the real barrier, not the research.
Systems inside it
- Plain language search
- Real supplier prices and shipping
- Market price and competitor check
- Country by country comparison
- Browser app, Windows build and Telegram bot