Custom Contact Search

The same mechanism supports two different jobs, and it helps to be explicit about which one you are running:

This is the main case for GTM and founder-led sales teams already running outbound. Apollo, Clay, and broad title filters return volume, but for a technical product the signal that predicts fit is rarely a job title — it is what someone actually works on, and that is not something a role or seniority filter can express.

Developer lead research scales when the reasoning is repeatable, not simply when the list becomes larger. In practice that means the product description turns into a fixed set of search angles, the same evidence-and-reasoning structure gets applied to every candidate, and weak matches get discarded before anyone looks up a contact. The angles themselves are reusable — a team refines them after a search and runs them again, instead of rebuilding the criteria from scratch each time.

That is the difference between a bigger list and a better process. See Custom Contact Search for the workflow itself.

Founders use the same mechanism differently: fewer candidates, reviewed more closely, usually feeding a direct first conversation rather than a running pipeline. At this stage, one developer who is genuinely close to the problem — someone who can try an early version, push back on an assumption, or explain why the workflow does not fit — is often worth more than a long list of generic contacts.

First Users Search is the entry point built specifically for this case, for founders without a sales team yet.

Job titles, company filters, and technology tags describe a market. They do not describe a specific person's proximity to a problem. Two developers with the same title, Software Engineer, can work on completely different systems — one maintaining CI infrastructure across dozens of repositories, the other building application UI and never touching CI configuration. A title filter treats them as equivalent even though only one is close to the problem this dev-tool solves.

Single-event lists have the opposite gap. A star, a fork, or an issue comment is a real action, but on its own it does not say whether it reflects active evaluation, a bookmark that never gets reopened, or a favor for a colleague.

The 2025 Stack Overflow Developer Survey found that 48% of developers endorsed or influenced a technology purchase in the last year — developers are often part of the buying process, but that does not mean every developer is a buyer, or that one public action is commercial intent. A useful search needs technical evidence that a developer is close to the problem, and enough product context to explain why that evidence matters for this specific product.

The walkthrough below is illustrative — a representative example of how the pieces connect, not a real candidate or customer record.

The product: a dev-tool that helps teams identify flaky CI tests. From that description, three search angles come out — concrete hypotheses about who is likely to run into this problem, not a generic persona like QA engineers:

A candidate matched against those angles might show public repositories using GitHub Actions with visible integration-test workflows, recent commits touching CI configuration, and an open issue thread about intermittent test failures.

The product-specific reason: maintains public projects that rely on GitHub Actions and automated integration tests, and recently opened an issue about intermittent failures — a plausible signal of firsthand exposure to flaky-test overhead.

The uncertainty worth naming: the issue could describe a one-off infrastructure problem rather than a recurring flaky-test pattern. The reasoning is a hypothesis worth verifying, not a confirmed need.

A possible opener: "Saw your issue about intermittent CI failures — I'm building a tool focused on flaky test detection and your project looked like a relevant case. Worth a quick look?"

What happens with the result depends on the mode from the section above. A founder doing first-user outreach reviews this one candidate closely before reaching out. A GTM team running the repeatable version reviews a batch built from the same three angles, keeps the ones where the evidence holds up, and reuses the angles on the next search.

A fixed score based on event type is easy to scale but difficult to trust — if every fork is worth ten points and every contribution twenty, the system ranks activity without knowing whether it matters to this product. The same developer can be highly relevant to one dev-tool and irrelevant to another, even though their public profile has not changed.

What scales instead is the process: product positioning turns into a set of search criteria, those criteria produce several search angles, and the same angles get applied consistently across a batch of candidates. Weak matches get dropped before a contact is looked up. The angles get refined based on which ones actually produced good candidates, and reused on the next search rather than rebuilt each time.

This does not mean unlimited volume or automatic outreach — see the responsible-use section below. It means the same reasoning can be run again next week, on a different search angle, without starting over.

Apollo, Clay, and developer-signal platforms are not direct substitutes for Custom Contact Search — they solve adjacent problems, usually a step later in the process:

Custom Contact Search sits earlier in the process. Its output — a reasoned shortlist — can feed into Apollo, Clay, or a CRM afterward; it is not trying to replace what those tools do once you already know who to contact. Common Room and Reo.dev sit closer to signal feeds — they connect predefined developer and community events into a broader GTM workflow rather than reasoning from a specific product description.

Public does not mean unrestricted. GitHub's Acceptable Use Policies place real limits on using GitHub information for spam or the sale of personal information, and privacy and direct-marketing rules vary by jurisdiction and channel.

The default result is a short, evidence-backed shortlist — a public profile, supporting signals, and a reason, without an email address. Finding a possible contact method does not by itself make outreach appropriate — the applicable laws, platform rules, and opt-out expectations for that person still apply, and that responsibility stays with whoever sends the message.

Before treating a candidate as relevant, ask: