How to Reach Developers Without Cold Emailing

Cold emailing a developer is a strange thing to do in 2026. Most engineers read exactly one email at work - the one from their manager - and route everything else into a folder they check twice a year. Your perfectly crafted pitch, the P.S. line with the subtle flex about a mutual connection, the CTA your growth lead swore by, all of it sits there unopened.

If your target is a developer, engineer, technical founder, DevRel person, or anyone who touches a GitHub profile regularly, you have a better move. Reach them where they already spend the day.

This post is the playbook. It works for sales reps pitching devtools, recruiters looking for senior engineers, founders who want a reply from another founder, and anyone whose target lives on the command line more than in their inbox.

Why email is broken for engineers

Two specific things make developers bad email targets:

1. They filter aggressively. The average engineer spam-filters any email that smells like "pipeline", "enterprise stack", "unlock velocity", or comes from a marketing automation tool. Your email does not land in their main inbox. It lands in a blob called "promotions" they never open.

2. They trust proof over polish. A well-written pitch with zero context gets ignored. An awkward one-line question in their GitHub notifications gets a reply in minutes. Developers reward evidence that you paid attention to what they actually do.

The good news: if you can show you read their code, commented thoughtfully on an issue, or contributed something small, you skip the filter entirely.

The GitHub issue method

Here is the core move, step by step. It sounds simple because it is.

Step 1 - Find their GitHub

Most engineers list a public GitHub on their company page, personal site, Twitter bio, or LinkedIn. If you have their name and company, finding the GitHub usually takes under 30 seconds. This is where Orit earns its keep: one search on a domain returns GitHub handles, commit emails, and profile links, grouped per person, so you do not guess.

Skip anyone whose GitHub is empty, not updated in the last year, or clearly a throwaway account.

Step 2 - Read their most recent public work

Not the pinned repos. The recent ones. Public activity in the last 30 days tells you what they actually care about right now, not what they worked on three years ago and pinned for resume vibes. Look at:

• Their last 3 commits on public repos
• Any issues they opened or responded to recently
• Any pull requests they merged

Fifteen minutes of this is enough. You are looking for one thing: something specific they would remember tomorrow.

Step 3 - Engage publicly, once, meaningfully

Find an open issue on one of their active repos that you genuinely understand. Leave a helpful comment. Not "following this, same issue here", which adds no value. A real comment: you reproduced the bug, you have a workaround, you caught an edge case, you pointed at a related change in another project.

If there is no good issue, open one yourself. Report a bug you actually encountered. Suggest a tiny feature with a clear use case. Attach a small reproduction script if relevant.

The point is not to pitch. The point is to put a positive interaction on record, so when your next touch arrives, you are not a stranger.

Step 4 - Reach out, briefly

After the public interaction, send a short message through the channel that fits:

• If their GitHub profile has a contact section with an email, use that.
• If not, their Twitter or LinkedIn is usually listed on their GitHub bio.
• Last choice: a comment on their last blog post or tweet, referencing your prior interaction on their repo.

The opener writes itself: "I opened the issue on X yesterday about Y. Saw you work on Z and thought I would reach out directly about something related." You already have credibility. You have one name in common - their project - and you used it.

Step 5 - Stop if they do not reply

One ignored message is a decision. Do not send a second. Do not send a third. A maintainer who gets cold DMs for every issue response stops reading issue responses, and you have just made the ecosystem worse for everyone. Move on and try another target.

When to NOT use this method

The GitHub issue method is honest and effective, but it has limits.

• Targets who do not code in public. Many senior engineers stop pushing to public repos once they are on a full-time job. Their GitHub shows tumbleweed. This method will not work.
• You have nothing real to say. If you cannot find or create a genuine reason to comment on their repo, do not fake it. Developers notice insincere engagement immediately. Skip the target.
• Urgent deals. The method takes days of genuine work. If you have a deadline this week, cold email is faster, even if it is less effective.

Variants by target type

Individual contributor engineers - GitHub is the first touch. Secondary: personal blog, dev.to, or Mastodon.

Senior engineers at public companies - GitHub may be cold. Better: their conference talks, podcast appearances, or Mastodon. One warm comment on their talk video works better than 10 cold emails.

Founder-engineers (CTO, indie hacker) - Mix GitHub + Twitter/X. They do both. Twitter DMs are usually open. Public reply to their last product update before DMing works wonders.

DevRel people - They WILL read your DM. But they also get 50 per week. Lead with a question about their docs or a specific thing you liked, not an ask.

Open source maintainers - Hands off. They are buried. If you have a genuine contribution, submit a PR. If not, leave them alone unless you are sponsoring. Sponsorship is a valid warm channel.

The fallback ladder

If GitHub does not pan out, here is the order to try for engineers specifically:

1. GitHub issue or PR - covered above
2. Public Twitter/X reply, then DM - works if they are active there
3. Conference talk or podcast comment - usually get seen because few people comment
4. Dev.to or Medium article reply - low volume, high response rate
5. Personal blog contact form - they put it there for a reason
6. Email - last resort. Keep it short: one line, one ask, one link

If you run this ladder, you will find about 40-60% of engineer targets reachable through something other than email, and your reply rates on the ones you do reach will roughly double.

What Orit does in this workflow

Orit is the discovery step. One search on a domain and you get GitHub handles, LinkedIn profiles, Twitter accounts, and any public email per person, plus a hint on where each channel is most active. That means you spend zero time hunting and all your time doing the actual outreach work that matters.

Concretely: for a typical B2B target domain, Orit surfaces 3-10 engineers per company with their GitHub already pinned on the result card. You click, you read their recent work, you run the steps above.

Takeaway

Developers are reachable. You just cannot reach them the way you reach a marketing VP at a Fortune 500. Show you care about what they built, give before you ask, and pick the channel where they actually spend time. Five minutes of real effort beats an hour of email sequence writing.

Run one domain through Orit. Pick one engineer. Follow the five steps above. If it does not work, at least you learned something about their repo.

---

Try Orit free: orit.app

One search per domain returns GitHub profiles plus any public channel per person. Free tier: 50 searches per month.