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 a checklist pass where the model's reasoning is pinned to structured 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.

7. 7. We count the customers and the money

   Calling an idea clear is not enough — it has to feed someone. The model estimates the segment size in customers and must state the basis: the number of stores on a platform, companies in an industry, installs of comparable products. The rest is computed in code: the revenue ceiling at a realistic share of that segment, and how many paying customers are needed to reach $10,000 per month. Thresholds differ by audience, because a business and a private person pay differently: business pays $50+ and needs hundreds of customers, a person pays $3-15 and needs tens of thousands.

   ceiling = customers × capture share (1% b2b / 0.2% b2c) × price; rejected if ceiling < $2000/mo

   Three situations are rejected outright because code cannot fix them: it is unclear who would buy; every customer needs custom work instead of configuration; customers cannot be reached without an ad budget. That is not taste — it is the absence of a business model.

8. 8. We check how it ended for those who already tried

   Launch stories feed the verdict alongside our own scores. Someone else's success on the same problem raises the score, a failure lowers it, and if several teams already tried and gained no users with no successes among them, the idea is rejected as a failure already on record — advocacy does not work against facts. Such stories used to sit on the idea page as "proof of demand", which was a mistake: two posts saying "100 days, zero users" stood next to a "strong idea" verdict.

9. 9. We answer who can actually build it

   "Solo-feasible" used to be a score from one to ten — you cannot decide anything with that. Now it is an answer: one person, two people, or a team. The model states how long one developer with an AI assistant needs and flags the roles AI cannot cover; turning that into a crew size is done in code, identically for every idea. More than six months alone means two people; two uncoverable roles mean a team.

   What AI changed: it covers code, integrations, migrations, UI, copy, docs, tests and first-line support, so "needs a designer", "needs a frontend developer" and "needs a copywriter" no longer count as people. What still counts is what cannot be replaced: long-cycle sales, on-call and SLA, licensed expertise, and the physical world — hardware, logistics, suppliers.

10. 10. We answer whether you need someone from the industry

    How much code an idea takes is clear from the project size. Whether you can write the spec at all without having worked in that industry was never stated anywhere. The model answers one question: what do you need in order to describe the rules — which fields, which conditions, what counts as an error. Technical difficulty does not count: the reader is the developer, only knowledge of someone else's business does.

    Domain-agnostic → Self-teachable → One-time insider → Industry expert required

    An idea that permanently needs an expert stays out of the top of the catalogue: you would pick it by score and then hit a search for a specialist instead of code. If on top of that the solution has to be reworked for every client, the idea is rejected and the advocate cannot save it.

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.