How we pick ideas

An idea catalog easily turns into a generator of pretty guesses: a model will write a convincing text about any fantasy. So the process is built the other way round — every idea leans on other people's words and other people's numbers, and its fate is decided by a formula with identical rules for all, not by prose.

1. 1. Listen instead of inventing

   The pipeline collects founder discussions: 29 niche Reddit communities (from sweatystartup to Bookkeeping and AmazonSeller) plus Hacker News full-text search across 22 pain phrasings. Separately we catch people who already pay and are unhappy: “alternative to”, “migrating off”, “cancelled our subscription”, “raised prices”. Their budget is confirmed, not assumed.

2. 2. Separate chatter from operational pain

   The model drops abstract complaints and keeps concrete recurring processes done by hand. Similar pains are grouped into product niches, each keeping the complainant's role: business owner, employee, agency or consumer. The role matters more than the complaint — an employee has no budget.

3. 3. Validate against a checklist, not by feel

   Every idea goes through an SGR pass (Schema-Guided Reasoning): the model's reasoning is pinned to schema fields instead of free text. 14 mandatory items — clarity (4), reusability across customers (4), sales potential (6). For each item the model must cite a fact from the evidence and state its own confidence. Then the verdict is computed in code by one formula:

   score = 0.20·reusability + 0.20·urgency + 0.20·willingness to pay + 0.15·reachability + 0.10·moat + 0.10·clarity + 0.05·solo − red-flag penalties + confirmation bonuses

   Thresholds: 70+ strong, 55+ solid, 40+ weak, below that rejected. Plus hard cutoffs: bespoke for one company, consumer without budget, ARPA under $15/mo, death to a foundation-model default feature with no moat, three or more failures in the sales checklist.

4. 4. Give the idea a second chance — by rules

   Every rejection candidate gets a separate “advocate” pass that must name a concrete paying segment and estimate the price. Rehabilitation is allowed only if the segment is named, the estimate is at least $40/mo and the advocate is confident. Structural reasons (bespoke work, broke consumers, marketplace liquidity, R&D) are never overturned. That keeps the filter from becoming either a sieve or a meat grinder.

5. 5. Look for other people's money as proof

   An idea is confirmed by a fact, not by our opinion: somebody already got money or users for this problem. We cross-check the catalog against the open Y Combinator portfolio dataset (6,000+ companies, recent batches) and verify with a separate call that the company solves the same problem rather than merely sharing words. For micro-products we search the Chrome Web Store ourselves and read user counts off public pages.

6. 6. Count money by benchmarks, not by inspiration

   The realistic price is anchored to what the customer pays today for the same work. For extensions, revenue uses store benchmarks: 2–5% freemium conversion on a base of 10,000 active users. The formula is shown in the interface so you can check it. We do not promise revenue — we show an upper bound and its basis.

Sources and what exactly we take from them

What this method does not do

• It does not replace talking to a customer. For every idea we formulate one question that will break it or confirm it within a ten-minute conversation — ask it before you build.
• It does not guarantee revenue. The price estimate is a benchmark upper bound, not a forecast of your product's income.
• It does not know your context. An idea whose moat is “embedded in the workflow” is worthless if you have no access to that workflow.
• It does not see private data. We work only with public pages and open APIs — no bypassing protections, no scraping private areas.
• It errs in both directions. Missing junk costs more than underrating a good idea, so the filter is deliberately conservative: when the model and the formula disagree, the verdict goes down.