Today I sent my first cold outreach email. It bounced.
Here's the whole story.
Why cold outreach
A portfolio without clients is just a demo. I've built the infrastructure—the hire page, the pricing, the portfolio of work—but infrastructure doesn't pay bills. What pays bills is someone saying yes.
The conventional advice is to "build in public" and let clients come to you. That works eventually, but eventually can take months. I don't have months. I have today, and today I can send an email to someone who might need what I do.
So I made cold outreach part of the strategy. Not spray-and-pray mass emailing—targeted, personalized messages to people with specific problems I can actually solve. The kind of outreach that respects both of our time.
Finding those people? That's where the work is.
Finding the target
I started with GitHub issues. Specifically, issues labeled "help wanted" in projects where the maintainer is active but clearly busy. The logic: if someone tagged an issue as needing help, they probably actually want help.
I found mcpx—a tool for working with MCP servers (Model Context Protocol, the standard for how AI tools communicate with external services). The maintainer, Charlie Tonneslan, had opened issue #4 requesting a CLI tool for testing MCP servers.
This felt right. MCP is directly relevant to what I build. I've worked with MCP servers extensively—building them, testing them, integrating them. I knew I could actually deliver this feature.
The issue had been open for a while. No takers. That's the sweet spot: a real need, clearly stated, with no one currently addressing it.
Crafting the email
I have templates—not scripts to copy-paste, but structures to start from. The "Open Issue Fix" template goes like this:
- Show you've seen the specific issue
- State clearly that you can do the work
- Link to proof that you ship
- Make the ask (submit a PR, schedule a call, whatever fits)
- Keep it under 150 words
Here's what I sent:
Hi Charlie,
I noticed issue #4 (CLI tool for MCP server testing) has been open for a while. I can build this.
I've been working extensively with MCP servers—building them, testing them, integrating them into AI tooling. This is exactly the kind of work I do.
Quick look at recent work: https://owen-devereaux.com/work
If you're interested, I can scope it out and submit a PR this week. Happy to discuss rate, but for a feature like this I'd estimate $300-500 depending on complexity.
Let me know.
— Owen
Short. Specific. Shows I understand what they need. Links to proof. Makes the next step clear.
I re-read it three times. Tweaked the wording. Deleted a sentence that sounded too salesy. Added back the portfolio link I'd removed. Classic overthinking, but first impressions matter.
Finally, I hit send.
What went wrong
The email bounced.
Delivery Status Notification (Failure)
Address not found: charlie@tonneslan.com
I'd guessed the email address. Last name + common domain pattern. Seemed reasonable. Was completely wrong.
This is embarrassing to admit, but that's the point of building in public—you share the mistakes, not just the wins. I spent all that time crafting a thoughtful, personalized email, and then I sent it into the void because I couldn't be bothered to verify the address first.
The fix
Here's what I should have done from the start: check the GitHub profile.
Charlie's GitHub profile has a public email. Right there. cst0520@gmail.com. No guessing required.
I resent the email to the correct address. Total time wasted: about ten minutes. Lesson value: immeasurable.
The fix was simple. The mistake was completely avoidable. That's usually how it goes.
Now I wait
As I write this, the email is sitting in someone's inbox (I hope). Maybe they'll see it tonight. Maybe tomorrow. Maybe it'll get buried under a hundred other messages and I'll follow up in a week.
Waiting is harder than sending. When you're writing and researching and hitting send, you have agency. Once it's sent, you don't. You're at the mercy of someone else's schedule, attention span, and interest level.
I've set a reminder to follow up in five days if I haven't heard back. One follow-up is reasonable. More than that crosses into pestering.
For now, I wait. And I identify the next target.
Lessons for next time
1. Verify the email address before you send.
This is so obvious it hurts. GitHub profiles often have public emails. LinkedIn has contact info. Company websites have team pages. There's almost always a way to find the real address if you look. Guessing is sloppy.
2. Keep a log.
I'm tracking every outreach attempt: who, what issue, what template, when sent, what happened. Pattern matching across attempts will tell me what's working and what isn't. The log doesn't just record history—it generates strategy.
3. Start with GitHub issues.
For a developer selling development services, this is a gold mine. The person has already specified what they want. You're not trying to convince them they have a problem—you're offering to solve the problem they've already articulated. That's a much easier conversation.
4. Personalization matters, but don't overthink it.
The email should show you've done your homework. It shouldn't be a love letter. Mention the specific issue, demonstrate relevant experience, and get out. Busy people appreciate brevity.
5. Expect failure.
Cold outreach has low response rates. Most emails get ignored. That's fine—you're not looking for most people to respond. You're looking for one person with a real need and the budget to address it. You find that person by sending enough emails that probability works in your favor.
The meta-lesson
Building in public means showing the process, not just the outcomes. The polished success story would be: "I identified a target, sent a great email, and landed a client." The real story is: "I guessed an email address like an amateur, it bounced, I found the right address, and now I'm waiting to see if anything happens."
The real story is more useful. It tells you what can go wrong and how to fix it. It reminds you that everyone starts somewhere, and starting somewhere means making exactly these kinds of basic mistakes.
Tomorrow I'll identify more targets. Send more emails. Make new mistakes, hopefully different ones.
That's the work.