From Star to Signed: A Framework for Converting GitHub Activity into Pipeline

Why a framework beats intuition

The star-to-signed funnel is the explicit pipeline that turns raw GitHub activity into signed DevTool contracts. It exists because the path from a public bookmark to a procurement signature has too many drop-off points to manage by feel. Every DevTool team that sells to developers ends up rebuilding some version of this pipeline; the ones that ship revenue are the ones that make each stage measurable and auditable from day one.

Without a framework, teams over-invest in the first stage they happen to notice — usually outreach. They write better emails, scale sequences, add channels. None of that moves the needle when the real leak is two stages upstream. The framework below forces a team to measure every handoff, which is the only way to discover where your actual constraint lives.

This approach sits on top of developer signal intelligence infrastructure. The framework is conversion-oriented; the intelligence layer is data-oriented. You need both.

Stage 1: Signal capture

Signal capture is the top-of-funnel intake stage. Its job is to pull every relevant event against an approved repo list — stars, forks, issues, watches, and pull requests — into a single event bus. Breadth matters more than precision here. Filtering events at capture time hides problems; filtering later makes drop-off visible.

What to capture

• Your own repos. Stars, forks, and contributors against the public surface of your product.
• Competitor repos. The same events against each competing tool in your category.
• Ecosystem repos. Tutorials, example apps, starter kits, and awesome lists that tend to attract your buyer.

What to measure

Volume per repo per week, event mix, and actor uniqueness. If your event count is flat week-over-week, the top of the funnel is starving the rest of it.

Stage 2: Deduplication

Deduplication collapses many events per developer into one durable actor record. The same developer will star three competing repos, fork one, and comment on an issue, all in a week. Without a dedupe stage, enrichment runs four times and outreach fires four times.

Dedupe uses the GitHub actor ID as the primary key. Email is not a stable identifier at this stage — it appears later, during enrichment. A single actor record should accumulate a list of events with timestamps and a running intent score. The score lets downstream stages prioritize without re-scanning the raw event log.

For an event-by-event taxonomy of what feeds this stage, see GitHub activity as a buying signal.

Stage 3: Enrichment

Enrichment attaches business identity to each GitHub actor. Company, role, seniority, email, and phone. Without this stage you have GitHub usernames; with it you have accounts and contacts. Enrichment is the single most expensive stage per unit of work, because every event that reaches it costs a data API call.

Order matters. Run dedupe before enrichment, not after. Running enrichment on raw events is the most common and most expensive mistake teams make when they skip the framework — it can inflate cost by 10× for no gain in conversion.

ICP filtering happens here

Once identity is attached, the actor is matched against an ICP profile. Wrong-size company, wrong geography, wrong role — these actors exit the funnel here and do not reach outreach. The ICP cut is the largest drop-off in a healthy funnel, and that is correct. Protecting sales capacity is the reason enrichment is paid for.

Stage 4: Outreach

Outreach is the first stage where a human is in the loop. Everything upstream should be automated; from here forward, the quality of the conversation is what moves the deal. Automating outreach content past the first touch is how teams produce the email sequences that developers filter out of their inbox.

Reference the developer outreach pillar for voice, channel, and cadence. The signal-aware edge is that the first touch should cite the specific event that flagged the developer — "saw your PR against the fork of …", not "I noticed you care about DevTools." Specificity is the only thing that earns a reply rate above 3%.

First-touch reply rate is the main metric for this stage. A healthy signal-based program should see 8–15% first-reply on developer personas when specificity is high. Below 5% usually means stage 3 is letting wrong-ICP actors through.

Stage 5: Close

Close is where the opportunity is qualified, demoed, scoped, and signed. This stage is mostly indistinguishable from a normal B2B SaaS close cycle, except that the champion is technical and the evaluation runs on real code earlier than it does in generic SaaS. Expect a technical validation step before any commercial conversation — the deck-first approach that works for horizontal SaaS will not work here.

Close rates in signal-based DevTool pipelines typically run 15–25% from first reply to signed. Teams that don't measure this don't know whether their problem is earlier in the funnel or on the close itself. A close rate below 10% usually indicates a targeting problem upstream, not a sales-execution problem downstream.

For a concrete starter-point scoring model that feeds priority ordering into this stage, see stars vs. PRs vs. commits.

The metric that matters

Stage-to-stage conversion rate is the only diagnostic metric that stays useful across seasons. Absolute dollars move with ACV, seasonality, and headcount. Conversion rates do not.

Track five rates on a rolling 90-day window:

• Capture → dedupe — high is normal; below 90% means you're missing actor-ID canonicalization.
• Dedupe → enrich — the most variable rate. Controlled by enrichment coverage.
• Enrich → outreach — ICP pass-through. Typical range: 15–35%.
• Outreach → reply — 8–15% is healthy for developer personas with specific first-touch.
• Reply → signed — 15–25% for mid-ACV DevTools.

Multiply through and you get the raw-star-to-signed rate: 0.1–0.3% for a tuned pipeline. This is small in absolute terms and large in relative terms, and it is the right denominator to use when sizing the top of the funnel. If your addressable repo stars per month don't multiply up to the pipeline dollars you need, the answer is more repos to capture against — not more sequences. Pair this with the taxonomy in GitHub intent data and the event classification in the repo intent score tool to size your capture universe concretely.

Frequently asked questions

What is the star-to-signed framework?

A five-stage pipeline — capture, dedupe, enrich, outreach, close — that turns raw GitHub events into signed DevTool contracts with explicit conversion rates at every handoff.

What conversion rate should I expect from stars to signed?

0.1 to 0.3% for mid-ACV DevTools. Forks convert at 2–5%, PRs to integration code at 10–20%.

Which GitHub signal feeds the first stage?

All of them. Breadth at capture is correct; filtering happens later at enrichment and ICP-fit.

Why run dedupe before enrichment?

Cost. One developer can generate four events in a week — enriching them four times multiplies your API spend without improving conversion.

When do humans enter the loop?

At stage four, outreach. Everything upstream should be automated; everything from outreach onward is conversation-driven and can't be scripted without losing credibility.

What metric should I watch weekly?

Stage-to-stage conversion on a rolling 90-day window. Dollars move with ACV and seasonality; conversion rates don't.