Discovery without the sprint

Product discovery is treated like a project phase. You kick it off, run some research, converge on findings, then move into execution. The signal you collected is current for maybe a week. Then it starts to decay.

That's the model most teams use. I think it's wrong.

Not wrong in the sense that research doesn't work. Wrong in the sense that you're treating a continuous signal problem as a one-time input. Opportunities show up in forums, in complaints, in workarounds (not in the window when you happen to be doing discovery).

So I built NVSBL to test whether an agent can keep looking while you're building.

The first agent: HN Scout

The first signal source is Hacker News. Specifically: the complaints. Ask HN threads, "workaround for X", the posts where someone says "I built this because nothing else did Y." These are unpackaged product opportunities.

HN Scout runs on a schedule. Each week it scans recent posts, sends them through an LLM analysis layer, and surfaces the ones that look like unmet needs. In the first working runs: 284 posts scanned, 30 labelled opportunity issues filed to GitHub, tagged by category.

30 from 284. Whether those 30 are actually worth building is a human question, which is why HN Scout doesn't try to answer it.

The review layer

The output of the scanner is not product. It's candidate opportunities for a human reviewer to assess.

That distinction matters. Fully automated opportunity validation is a different and harder problem. The value of the agent is in the scan: it keeps looking at scale, consistently, on a schedule. What it surfaces gets reviewed by someone who can judge commercial potential, competition, and fit.

Reviewed opportunities that pass become the approved feed, packaged through the public API. Subscribers consume them through an API key. Qualified findings can land as Linear issues in a subscriber's workspace. That's the loop.

Three repos, one question

NVSBL is three separate repos because each layer has different evidence requirements.

nvsbl is the private engine. No UI. Agents run, results flow to GitHub Issues for review. Nothing is exposed until it's been approved.

nvsbl-web is the public surface: the feed of approved opportunities, the request-access CTA, the API. What's public is what's passed review.

nvsbl-app is the authenticated layer: API keys, usage, billing, Linear integration, pipelines. The product layer for buyers who want a continuous flow of reviewed signal into their workflow.

Keeping them separate keeps the evidence boundaries clean. You can show the public site without showing the engine. The engine can accumulate signal without the app being ready.

What I learned from the first run

HN Scout worked as expected. The LLM scoring separated posts with clear pain signals from posts that were just complaints about life. The labelled issues were legible and could be reviewed in 30 minutes.

What I didn't expect: the value isn't the individual opportunity. It's the accumulation. After four or five runs, the GitHub Issues backlog starts to look like a map. Themes emerge. The same unmet need surfaces from multiple directions. That's a different kind of signal than a research sprint produces.

A research sprint gives you depth on one area at a time. A continuous scanner gives you breadth across everything, updated weekly. The scanner doesn't replace talking to users. It tells you where to aim.

The thesis under test

NVSBL is live at nvsbl.dev. The scanner is running. The public feed exists. The API is built but not yet selling.

What I'm testing is whether a small team (currently me) can get enough reviewed signal, fast enough, to make the API worth buying. That's the product question. The delivery loop is wired. Whether product teams will pay for a continuous feed of reviewed opportunities, pre-structured for their workflow, is what the next phase finds out.