I ran 521 Show HN launch URLs through a lead filter: 86 companies survived

Every "B2B lead list" problem starts with the same question: where did the domain come from? On job boards the employer's domain sits inside the body copy of an ad, which is why roughly half of what gets extracted turns out to be the board itself, an ATS, or a link in the text. Show HN is the opposite: the post has a structured url field, and that field is the maker's own site.

So I pulled Show HN and ran it through a filter. Here is the whole pipeline and every number, including the ones that did not survive.

The pull

Hacker News has a public search API (Algolia). Twelve pages of search_by_date with tags=show_hn, 100 hits per page, gave 521 hosts that came from the url field of a post — no text parsing, no guessing. Each candidate kept the HN item id as its provenance, so a row can always be traced back to the launch it came from.

Filter 1 — remove what is not a company

A launch URL is often not a company's own site: GitHub repos, YouTube demos, Medium posts, news stories, and free PaaS subdomains (*.vercel.app, *.pages.dev, *.onrender.com, and friends). After a blocklist of those, 223 of the 521 hosts were new against an existing file of 6,518 company domains. The other 298 were already known — which is itself a signal that this source is not a duplicate of job feeds.

Filter 2 — a domain is not a company until it answers

Every host was requested live, and kept only if it answered 200 and the page looked like a product rather than a document: pricing, sign-up, "get started", a demo link. That left 112. The 111 that dropped out were mostly one-page demos, portfolios, and blog posts about a tool rather than the tool.

Filter 3 — the subdomain trap

This is the step I would keep even if I deleted every other one. A launch URL is frequently a page, not a domain:

• app.oghmere.com, shop.lumnika.com, demo.plutus-cloud.com → three rows for what is one company each
• blog.codacy.com → a content subdomain of a company already in the file
• what-are-you-working-on-62u6b.reachpad.app → an app instance on someone else's PaaS, not a company domain at all

Normalising to the registrable domain and re-checking the root took 112 → 105 unique candidates → 86 that answered 200 at the root. Nineteen were deep links whose root did not carry the product signals, and a handful were PaaS subdomains with no company behind them.

What the file looks like now

The filter above is one source family in a file I keep building from public sources only. Current state, counted row by row:

Two numbers in that table are worth more than the total:

1. Directory rows publish an address 99% of the time. Hiring threads do it 11% of the time. A hiring post gives you the company, not the contact.
2. Only 16% of rows publish an address at all. The rest are either checked one by one over SMTP or left out of the send queue — which is the actual cost of outbound, and the reason a list is an input rather than a product.

Why this is a lead-generation post and not a data-hoarding post

Collecting domains is the cheap half. The expensive half is what happens after: four checks before a row is ever sent (domain from the post, host answers live, published address matched to its own domain, mailbox checked where it will be used), then the volume question. A strict two-variant test needs 13,914 contacts per arm — 56 days at 500 a day. Below that, the honest output of outbound is not a conversion rate, it is a reading list: which segment answers, which sentence earns a reply, which objection comes back first.

Anyone quoting appointments per month before the segment has been read is quoting the report, not the meetings.

If you want the list, the checks and the sending run owned by someone else: appointment setting, scoped at $900 / $1,900/month / $2,900. The full source table and the four checks live on the canonical page for this article: appointment-setting-service.html.