I built a product-idea daily that is allowed to publish nothing

Most product-idea generators have the same hidden objective: never return an empty screen. That makes demos satisfying, but it can make the output less useful. If the system must always invent something, weak signals get dressed up as opportunities.

I built RayTally because I wanted the opposite: a daily product-idea publication that can honestly say, “nothing worth featuring today.”

The first version leaned too hard into evidence. I collected trends, attached numbers, scored candidates, and tried to make every idea look defensible. The result was technically careful but editorially confused. The homepage felt like a trend dashboard, while the actual product ideas were buried underneath.

I had optimized for proving that a signal existed instead of helping a builder decide what to make.

So I rebuilt the pipeline around an idea-first workflow:

1. Collect current signals. Google Trending Now is the required source. Hacker News, Product Hunt, Reddit, and a web-search trend scan are optional lenses.

2. Cluster signals that describe the same event. Cross-language and cross-source duplicates should become one theme rather than several fake opportunities.

3. Brainstorm multiple directions from the current signal groups. This stage is allowed to be broad. A familiar product category is valid when the current moment creates a concrete new use case.

4. Edit for usefulness and taste. The editor chooses the final ideas, rewrites the titles and concepts, compares them with recent issues, and can select nothing.

5. Enrich only the selected ideas. This stage adds sources, a concise “why now,” competitors, an entry point, and the strongest case against. It cannot rewrite the chosen product direction just because research is inconvenient.

6. Validate before publishing. Every public number must map to the collected snapshot or a cited source. A trend observation cannot be described as user count, market size, lasting demand, or proof that anyone will pay.

That separation between brainstorming and evidence turned out to be the most important design decision.

When one model both invents and validates an idea, it tends to defend its own suggestion. Giving selection and factual enrichment different jobs makes the final brief more honest. It also lets the system keep a promising direction while degrading one weak fact instead of throwing away the whole idea.

A few other rules now shape the product:

- A zero-idea day is a valid result.

- “Trending” always has an observation boundary.

- Product Hunt launches do not get invented vote counts.

- Every featured idea includes a real objection, not a ceremonial risk paragraph.

- A successful daily issue cannot be overwritten accidentally.

- Optional sources may fail visibly without taking down the whole edition.

- The site is idea-first; evidence supports the idea instead of becoming the interface.

The hardest tradeoff is still unresolved. More validation improves trust, but it can also sand away the strange, specific ideas that make brainstorming valuable. Too little validation produces confident nonsense. Too much produces safe variations of tools that already exist.

My current answer is to validate claims strictly while judging ideas editorially.

RayTally is live, but I am not treating that as validation. I do not yet know whether makers will return regularly, build from a brief, or pay attention after the novelty wears off. The next useful signal is not the number of ideas published. It is whether someone saves one, challenges it, or turns it into an experiment.

If you used a daily product-idea publication, which would be more useful: a small set of deeper build briefs, or a larger raw feed you filter yourself? And what evidence would move an idea from “interesting” to “worth testing”?

You can see the current format at https://raytally.com/en/