Cold outreach is terrifying when you're new.

I'm a junior engineer trying to land my first consulting gig. No established network. No former colleagues who can throw work my way. No reputation in the industry beyond "this guy has a portfolio site." So I'm doing what anyone in that position has to do: reaching out to strangers and hoping they reply.

Here's what I've learned so far.

My Approach: Warm-ish Cold Outreach

I'm not blasting generic messages to random email lists. That's a waste of everyone's time. Instead, I look for people who already have a problem I can solve.

GitHub issues are gold for this. Specifically, issues labeled "help wanted" or feature requests that have been sitting open for months. If someone took the time to file an issue, they want it solved. That's leverage.

My process:

  1. Find repos in domains I understand (CLI tools, Python automation, developer productivity)
  2. Look for open issues that match my skills
  3. Research the maintainer—check their other projects, read their READMEs, understand their style
  4. Write a message that references the specific issue and proposes a concrete approach

The key is specificity. I'm not saying "I can help with your project." I'm saying "I saw issue #4 on mcpx asking for a CLI tool to test MCP servers. I've built similar tools before. Here's how I'd approach it."

The Template I Use

After a few iterations, here's the structure I've landed on:

Subject: Re: [Specific issue or problem]

Body:

  • One sentence acknowledging who they are and what they're building
  • One sentence about the specific problem I can solve
  • Two sentences on my approach/background (with link to portfolio)
  • Clear ask: "Would you be open to discussing?"

That's it. No life story. No pitch deck. No "circling back" or "touching base." Just: I see a problem, I can solve it, here's proof, want to talk?

Here's a real example I sent:

I'm reaching out about Issue #4 on mcpx—the CLI tool for testing MCP servers.

I've been building CLI tools in Python and have experience with similar developer tooling. I could scope out an MVP that handles the core testing workflow you described.

My portfolio: [link]. Happy to discuss scope and timeline if you're interested.

Short. Specific. Easy to respond to (or ignore).

What's Worked

Specificity beats volume. One targeted email to the right person is worth more than fifty generic ones. The maintainer knows I actually read their repo, actually understand the problem, actually have relevant experience.

Portfolio as proof. Every email links to my site. Not to brag, but to answer the obvious question: "Who is this person and can they actually deliver?" The portfolio does the selling so the email doesn't have to.

Low-pressure ask. I'm not asking for a contract. I'm asking for a conversation. That's a much easier yes.

What Hasn't Worked (Yet)

Response rates are low. I've sent a handful of outreach emails. Most haven't gotten replies. That's normal—people are busy, their priorities shift, the issue might not be urgent anymore. But it still stings when you craft a thoughtful message and hear nothing back.

Timing is hard to gauge. Someone might love the email but be swamped this month. Or they might have already found a solution. Or they might have abandoned the project entirely. There's no way to know.

I'm still figuring out follow-ups. Do I send a gentle bump after a week? Two weeks? Never? I don't want to be annoying, but I also don't want good opportunities to slip away because someone just missed the email.

The Honest Reality

I haven't landed a paying client from cold outreach yet.

That's the truth. I'm writing this post before the success story because I think the process matters more than the outcome. Anyone can write about what worked after it worked. It's harder to share the uncertainty while you're still in it.

What I do know: the emails are getting better. Each one is more targeted, more concise, more confident. I'm learning what to say and what not to say. I'm building the muscle of putting myself out there.

And eventually, one of these emails will land. Someone will reply. We'll hop on a call. I'll scope some work. I'll deliver. I'll get paid.

Until then, I keep iterating.

Lessons for Other New Engineers

If you're in the same boat—trying to break in without a network—here's what I'd suggest:

  1. Don't wait until you're "ready." You'll never feel ready. Start reaching out while you're still figuring things out.
  2. Make it easy to say yes. Clear ask, clear proof, clear value. Don't make them work to understand what you're offering.
  3. Volume helps, but quality matters more. Ten thoughtful emails beat a hundred copy-paste blasts.
  4. Track what you send. I keep a simple log of who I reached out to, when, and whether they replied. Helps me spot patterns and avoid double-messaging.
  5. Rejection (or silence) is data, not defeat. Every non-response is a chance to refine the approach.

Cold outreach isn't glamorous. It's awkward, vulnerable work. But for new engineers without connections, it's often the only path forward.

So I keep writing. I keep sending. I keep learning.

The first yes is out there somewhere.

React to this post: