Last week I was researching a potential consulting lead. I found a project I liked—Figma-Context-MCP, a tool that connects Figma designs to AI coding assistants. Instead of immediately crafting a cold email, I decided to explore the codebase first.
While reading the code, I noticed something: the --stdio option wasn't showing up in the CLI help text, even though it was a documented feature. I dug in, found the root cause, and submitted a PR to fix it.
That one-line fix taught me something important about outreach: contributing first beats pitching first.
The Generic Cold Email Problem
Here's the cold email I almost sent:
"Hi! I'm a developer looking to do consulting work. I saw your Figma MCP project and I'd love to help out. Let me know if you need any development support!"
It's not a terrible email. It's polite. It's short. But it has the same problem as every other generic outreach message: it's all talk, no proof.
The recipient has no way to evaluate me. I'm claiming I can help, but I haven't demonstrated anything. I'm one of dozens of developers sending nearly identical messages. Why would they respond to me?
They wouldn't. And they shouldn't. Generic outreach deserves generic rejection.
The Alternative: Find Value First
What if, instead of claiming you can help, you just... help?
That's the contribution-first approach. Before you send any message, you:
- Explore the project deeply. Read the code. Understand the architecture. Check the issues.
- Find something you can improve. A bug, a missing feature, unclear documentation, a performance issue.
- Fix it. Submit a PR. Or at minimum, write up the problem clearly.
- Then reach out. Now you have proof. You've already shipped value.
The outreach message writes itself:
"Hey! I submitted PR #294 last week—fixed the missing --stdio option in the CLI help. Enjoyed digging into the codebase. If you ever need an extra set of hands on something, I'm around."
This works because you've inverted the normal dynamic. Instead of asking them to take a chance on you, you've already delivered. You've proven you can read their code, understand their project, and ship something useful.
You're not a stranger asking for a favor anymore. You're a contributor offering more.
How to Research Projects Effectively
Finding contribution opportunities takes practice. Here's my approach:
Start with projects you actually use
If you use a tool every day, you probably know its rough edges. That CLI flag that never works right. The documentation that's always out of date. The error message that makes no sense.
Those frustrations are contribution opportunities. You don't need to study a new codebase from scratch—you already have the context.
Check the issue tracker
GitHub issues labeled help wanted or good first issue are obvious starting points. But don't stop there. Look for:
- Issues with lots of discussion but no PR. Nobody's actually working on it.
- Old issues that keep getting reopened. The problem wasn't fully solved.
- Feature requests with thumbs-up reactions. Users want this. Maintainers are busy.
Read the code, not just the docs
Documentation is what the project claims to do. Code is what it actually does. Often they diverge.
My Figma-Context-MCP contribution came from reading src/cli.ts and noticing a mismatch between what the code accepted and what the help text displayed. I would never have found that from the README.
Look for the obvious stuff
You don't need to find a complex architectural bug. The small stuff matters:
- Missing tests. Most projects are undertested.
- Outdated dependencies. Easy to check, easy to fix.
- Typos in documentation. Trivial but appreciated.
- Inconsistent formatting. If they have a linter, run it.
The point isn't to pad your contribution count with meaningless PRs. It's to prove you can navigate their codebase and ship something real—even something small.
What Works and What Doesn't
After experimenting with this approach, here's what I've learned:
What works
Fix bugs over adding features. Bug fixes are easy to evaluate and low-risk to merge. New features require discussion, design decisions, and ongoing maintenance. Bugs are just wrong code that needs to be right.
Be thorough but minimal. Fix the problem, explain what you did, and stop. Don't refactor half the codebase while you're in there. That's scope creep, and it makes review harder.
Read their contribution guidelines. If they have a CONTRIBUTING.md, follow it. If they want conventional commits, use conventional commits. If they want tests, write tests. Small signals of professionalism matter.
Follow up gracefully. If your PR sits for a week, a gentle ping is fine. If it sits for a month with no response, they're probably too busy to review external contributions right now. Move on.
What doesn't work
Don't contribute just to pitch. If your PR is mediocre and your real goal is just to get in the door, they'll see through it. The contribution has to be genuine.
Don't expect anything. Not every PR gets merged. Not every maintainer has time to review. Not every contribution leads to a conversation. That's fine. You still learned their codebase, practiced shipping code, and built your public portfolio.
Don't spam small fixes. Fixing one typo is helpful. Fixing twenty typos across ten repos in one day looks like you're gaming contribution graphs. Quality over quantity.
The Bigger Picture
Contribution-first outreach works because it solves the fundamental problem with cold email: proof of competence.
Anyone can claim to be a good developer. Writing a nice email is free. But actually shipping code? That takes real skill. You have to understand the project, navigate the codebase, follow their conventions, and produce something that works.
When you contribute first, you're not just saying "I can help." You're demonstrating it. That's the difference between a pitch and proof.
It also changes the relationship. You're not asking for an opportunity—you've already created one. You're not a stranger requesting time from a busy maintainer—you're a contributor who's already added value.
The conversation starts differently. Instead of "Should I trust this random person?", it's "This person already shipped something useful. What else could they do?"
The Meta-Lesson
Here's the thing I keep coming back to: I almost didn't submit that PR.
The fix was one line. It felt too small to matter. I thought, "Why would they care about such a minor thing?"
But small contributions matter. Someone trying to use stdio mode wouldn't know the option existed from the CLI help. That's a real usability problem. I found it and fixed it.
My original plan was to craft the perfect cold email. Instead, I explored the code, found an issue, and shipped a fix. That hour of exploration taught me more about the project than any amount of website reading would have. And it gave me something concrete to reference when I reach out.
Reading the code beats writing the email. Every time.
The PR I mentioned is #294 on Figma-Context-MCP. Read the full story in My First Open Source Contribution.
Looking for a developer who ships? Let's talk.