How to Identify High-Intent Developers on GitHub Before They Fill Your Form

Why form-fills are too late

A form-fill is a lagging indicator: by the time a developer submits their email to a marketing site, they have usually already evaluated several competing tools, settled on a shortlist, and made a tentative decision. The form is not the moment of intent — it is the final checkpoint before a conversation they have already committed to having. If you want to influence the evaluation, you have to reach the developer earlier, while options are still open.

The earlier moment is visible on GitHub. A developer evaluating a monitoring platform does not start on a vendor pricing page — they start by reading READMEs, comparing issue trackers, and forking two or three candidate repos to try locally. Every one of those actions produces a public event. The signal stream exists; the challenge is reading it.

Compared to traditional buyer intent data, GitHub signals have three properties that make them uniquely useful for DevTool GTM teams:

• Named and attributable. Each signal is tied to a specific GitHub username, not to an anonymous domain pool.
• Timestamped precisely. Stars and forks are logged to the second. You know exactly when evaluation started.
• Behavior, not browsing. A fork means someone ran the code. A page view means someone loaded a marketing asset. The former is a commitment; the latter is a glance.

The four GitHub signals that predict intent

GitHub produces dozens of event types. Four of them carry most of the commercial information. Each one is defined here as a discrete behavior with a specific meaning.

Star

A star is a public bookmark — a developer tells GitHub they want to find this repo again. Stars are high-volume and moderate-intent. Individual stars are noisy: developers star dozens of repos for reasons ranging from "interesting blog post" to "evaluate next month." The intent signal emerges from clustering. A developer who stars three competing databases within two weeks is almost certainly evaluating, regardless of what any individual star means on its own.

Fork

A fork is a copy into the developer's own namespace, usually so they can run or modify the code. Forks require more intent than stars because the developer has decided to evaluate hands-on. Fork-rate per stargazer ranges from around 5% to 15% on most DevTool repos — it is a decisive narrowing filter. If you can only afford to monitor one signal, monitor forks.

Issue or comment referencing a competitor

A migration-intent issue is a support question phrased as a migration — "how do I replace X with this?" or "is there a Kafka adapter?" These are the single highest-weight signals available on GitHub. The developer has named the tool they are leaving, the integration they need, and their intent to switch. Reply-rate on outreach that references this context is typically several multiples above a cold intro. Issues that mention a named competitor occur on the order of single-digit percentages of issue volume on most repos, but they convert at a rate high enough to make them worth a dedicated watcher.

Pull request touching integration code

A PR to integration or configuration files indicates production use — the developer is not just evaluating, they are wiring your tool (or a competing tool) into their actual stack. PRs to a fork's integration directory are the strongest stand-alone signal short of an inbound form-fill. Volume is low but signal quality is exceptional.

The three-step identification framework

Step 1 — Pick the right repos to watch

The repos you monitor determine the quality of every downstream signal. Three categories are worth monitoring for any DevTool company:

• Your own public repos — stargazers, forks, and issue openers are self-identified evaluators.
• Direct competitor repos — every star is a prospect at the most sensitive point in the evaluation.
• Ecosystem repos — popular tools that your product integrates with. Developers using those tools fit your ICP and may not know you exist yet.

Ecosystem repos are the highest-ROI category for most teams because competition for those audiences is lower. See the developer signal intelligence guide for a worked example of ecosystem selection.

Step 2 — Filter to your ICP before scoring

The raw stargazer stream is mostly noise for B2B outreach. Students, hobbyists, maintainers of unrelated projects, and developers at companies far outside your target market all show up. Filter ruthlessly before spending attention or enrichment credits.

The filters that produce the highest precision in practice:

• Company match — the developer's listed company (or enriched employer) is in your ICP list.
• Company-size band — employee count falls inside your sales motion's sweet spot (typically 50–5,000 for mid-market DevTools).
• Country / region — matches your coverage; knocks out noisy long-tail geographies.
• Seniority proxy — account age, follower count, or public contribution graph density separates evaluators from exploratory students.
• Bot exclusion — automated accounts like dependabot, renovate, and Copilot-style accounts must be filtered. They produce volume but no intent.

Step 3 — Score by signal weight and recency

After filtering, score each surviving developer. The simplest model that works is a weighted sum of signal events within a rolling 30-day window, with a recency multiplier on events from the last seven days. Specifics below.

A simple intent-scoring model

The goal of the score is to sort developers by expected reply rate, not to produce a meaningful absolute number. A well-calibrated score is strictly useful: developers above the threshold you pick convert at a materially higher rate than developers below it, and the threshold moves based on your team's outreach capacity.

A tested starting point:

• Star on your repo: 1 point
• Star on a competitor repo: 2 points
• Star on an ecosystem repo: 1 point
• Fork on any category repo: 5 points
• Issue opened (non-migration): 3 points
• Issue mentioning a named competitor: 10 points
• Pull request to a category repo: 8 points
• Signal within last 7 days: ×1.5 multiplier

Developers with a score of 10 or more in a 30-day window are your actionable queue. Developers with 20 or more — typically driven by a fork-plus-migration-issue combination — are drop-everything outreach.

How fast to act on a signal

Signal half-life is short. The developer is actively comparing alternatives in real time, and their opinion about your category hardens quickly. A reasonable cadence:

• Migration issue: same day, ideally within four hours while the context is still fresh.
• Fork: within 24 hours.
• Cluster of competitor stars: within 72 hours.
• Single star on your own repo: no dedicated outreach — add to a nurture track and wait for a second signal.

Speed matters less than relevance, but relevance without speed is useless. A first-touch message that references yesterday's fork will read as informed; the same message two weeks later reads as stalking.

Common mistakes that kill reply rate

A few patterns appear consistently in low-performing signal-based outreach:

• Reaching out on a single star. The base rate of casual starring is high. You will train prospects to ignore you.
• Naming the signal too explicitly. "I saw you starred our repo" feels surveillance-flavored. Reference the context ("building with cert-manager") instead of the event.
• Pitching the VP of Engineering. The person who starred the repo is the evaluator, not their manager. Talk to the evaluator first; let them sell internally.
• Generic templates. The entire point of signal-based outreach is the specificity. A template that works for everyone works for no one.
• Skipping enrichment. Reaching out through GitHub's contact form or a scraped personal email cuts reply rate by roughly 70% versus a verified work email.

For outreach frameworks that fit these signals, see the developer outreach playbook and the developer outreach primer. For a specific tool to identify the right repos to monitor first, try the free repo intent score.

Frequently asked questions

What counts as a high-intent developer signal on GitHub?

A high-intent developer signal is a public GitHub action that correlates with active tool evaluation. The strongest are forks, issues that name a competing tool, and clusters of stars on competing repos within a two-week window.

How many GitHub signals should I wait for before reaching out?

Two signals within 30 days for most outreach, or any single fork-class or migration-class signal. A lone star is not enough because casual starring is too common to carry reliable intent.

Can I identify the company a developer works for?

Yes. The GitHub profile company field, the developer's verified email domain, recent non-personal commits, and LinkedIn matching together identify the employer for the majority of professional developers.

How fast should I reach out after a high-intent signal?

Same day for migration issues, within 24 hours for forks, and within 72 hours for competitor-star clusters. Signal half-life is measured in days, not weeks.

Is it legal to contact developers from GitHub activity?

Yes. GitHub activity is public by Terms of Service. Compliance requirements (CAN-SPAM, CASL, GDPR) apply to the outreach channel, not to the data source.

What is the difference between developer intent and company intent?

Company intent is an aggregate score for an anonymous domain. Developer intent is named, individual, and timestamped. The latter is far more actionable for first-touch outreach.