NVSBL.APP
Hacker News, watched by an agent. Classified and filed in Linear.
A product team can move from "I should be reading Hacker News systematically and I never do" to "classified HN signal is appearing in our Linear backlog without anyone touching it" in under five minutes of setup. First issue lands within twenty-four hours, often within the first hour.
Discover
We kept seeing the same gap in product engagements with category-leading B2B teams. Their customers were all over Hacker News — complaining, requesting, comparing, churning publicly — and the product team had no system for capturing any of it. Engineers and PMs would scroll HN on the train, mention an interesting thread in Slack, and lose it within twenty-four hours.
We interviewed product managers, founders, and engineering leads at companies whose products live in HN-active categories — devtools, infra, AI/ML, B2B SaaS. The pattern was identical:
- •Pain about their category appeared on HN at higher density than on any other public source.
- •"I should be reading HN systematically" was a sentence nearly every PM said. Almost none of them did.
- •Existing social listening tools didn't solve it because they returned brand mentions, not pain — and certainly not pain in the shape an engineering team can act on.
- •The real bottleneck was triage. Even when a PM saw the signal, converting it into a Linear-shaped artifact required effort that always lost to other priorities.
"I have eight HN tabs open right now and I'll close them at the end of the day without doing anything about them. There's a feature in there somewhere. I just don't have a way to extract it."
— Head of Product
Define
The problem, sharpened
Product teams in HN-active categories cannot reliably extract actionable signal from Hacker News at the rate at which it appears.
Success metric
A team should go from no-system to "classified HN signal landing as Linear issues" in under five minutes of in-product setup. Acted-on rate on classified issues — the proportion that move out of triage within seven days — should be at least 1 in 5.
Scope boundaries
- •Hacker News only at launch. Other sources are user-voted from day one.
- •Linear only at launch. Other destinations are user-voted from day one.
- •We are not building a feedback platform. We integrate with the system product teams already use to triage work.
- •Classification produces structured signal, not roadmap recommendations. Humans decide what to build.
Riskiest assumption
That a domain-tuned classifier could distinguish actual category-relevant pain from off-topic chatter on HN with high enough precision that PMs would trust the output without re-reading every source. If the classifier was noisy, the product was pointless. We tested this assumption first — ran the classifier on three months of HN history across target categories before we built any of the rest of the system. The precision rate cleared the trust threshold. Cluster precision is now part of the eval suite that runs on every release; regressions block deploys.
Design
Topology
Three agents in a directed graph. An Ingest agent polls the official Hacker News API every five minutes, normalizing posts and comments into a common schema with full text, metadata, and source URL. A Classify agent applies category filtering, classification (feature request, bug, competitor mention, churn risk, raw pain, opportunity, support gap), and confidence scoring against the customer's category description. A File agent writes a Linear issue, formatted to the customer's defaults — labels, assignee, priority — with the original quote, the source URL, the classification, the confidence score, and a short rationale.
Prompt and policy decisions
- •Prompts are versioned in the repository; each Linear issue includes the prompt version that classified it.
- •Issues never invent quantitative claims. Source citations are mandatory.
- •Confidence scores are exposed in the issue body. Below-threshold items are dropped, never filed.
- •A "rationale" string ("classified as feature request because...") is included on every issue. Trust is built through explainability.
Eval design
- •Classification accuracy (does the label match human judgment).
- •Category fit (would a PM in this category triage this).
- •Citation faithfulness (does the rationale trace back to the source).
Trade-offs documented
- •Recall vs. precision — we chose precision. Better to miss a real signal than file noise. Customers can tune toward recall by lowering the score threshold.
- •Latency vs. confidence — we chose confidence. Most signal lands in Linear within five minutes of appearing on HN, which is fast enough.
- •Source breadth vs. integration depth — we chose depth. One source and one destination, both done extremely well, beat four of each done shallowly. Future sources and destinations ship by user vote.
Deliver
Stack
Next.js 15 on Vercel for the marketing site and dashboard. Node/TypeScript on Vercel functions for workers. Postgres for state. Inngest for the agent orchestration. Stripe for billing. Linear's GraphQL API for the write surface.
What we measure in production
- •Time-to-issue (HN post → Linear issue).
- •Classification precision against a sampled audit.
- •Acted-on rate — the proportion of generated issues that move out of triage within seven days. This is the only metric that ultimately matters.
- •Source health (HN API availability, our backlog depth).
Have a problem like this we should build for?
If you've got a recurring pain in your operation that you wish was solved off-the-shelf, we'd like to hear about it.
Talk to us