How do I pitch a technical article to a dev newsletter?

To pitch a technical article to a dev newsletter, make the editor’s job easy: show why the piece matters to their audience, why you’re the right person to write it, and what the article will concretely deliver.

A good pitch usually includes

1. A strong subject line

   • Example: Pitch: Practical guide to reducing API latency in Node.js
   • Or: Article idea for [Newsletter Name]: [clear topic]

2. A short intro

   • Who you are and why you’re reaching out.

3. The article idea

   • 1–3 sentence summary of the piece.
   • Be specific about the problem and the angle.

4. Why it fits their audience

   • Tie it to what their readers care about: tooling, performance, debugging, architecture, AI, dev productivity, etc.

5. Your credibility

   • Relevant experience, projects, or past writing.
   • If you have a blog, GitHub, or published work, include links.

6. Why it’s timely or useful

   • Mention a recent change, common pain point, or emerging trend.

7. A quick outline

   • 3–5 bullets showing the structure of the article.

8. A clear ask

   • Do you want them to greenlight the idea, suggest a better angle, or let you submit a draft?

---

What editors like to see

• Originality: not a generic “intro to X” unless you have a fresh angle.
• Actionability: readers should learn something they can use right away.
• Relevance: aligned with the newsletter’s usual topics and tone.
• Specificity: concrete examples, code, benchmarks, or lessons from real work.

---

Keep the pitch concise

Aim for 150–300 words unless the publication asks for more. Editors skim a lot.

---

Sample pitch email

Subject: Pitch: A practical guide to debugging flaky CI in GitHub Actions

Hi [Editor Name],

I’m [Your Name], a backend engineer/writer who’s spent the last few months digging into why CI pipelines fail intermittently in GitHub Actions.

I’d like to pitch an article for [Newsletter Name]: “How to Debug Flaky CI in GitHub Actions Without Guessing.” The piece would walk through the most common causes of intermittent failures—dependency caching, race conditions, environment differences, and test ordering—and show a repeatable debugging workflow using logs, reruns, and isolation steps.

I think it would be a good fit for your readers because many dev teams are dealing with CI instability, and the article would be practical rather than theoretical. I’d include:

• How to identify whether the flake is in the test, environment, or runner
• A step-by-step debugging checklist
• Example logs and fixes from real cases
• Simple guardrails to prevent regressions

I’ve written about [topic] before here: [link]. I also maintain [project/repo] and have hands-on experience with this problem.

If this sounds interesting, I’d be happy to send a draft or adjust the angle to fit your newsletter.

Best, [Name] [Portfolio/GitHub/Twitter/LinkedIn]

---

A few tips

• Study the newsletter first and mirror its tone and depth.
• Pitch one idea at a time unless they ask for multiple options.
• Avoid overexplaining your background.
• Don’t be generic: “10 tips for better coding” is too broad.
• Offer a takeaway: benchmarks, checklist, code samples, or lessons learned.

If you want, I can also help you draft:

• a pitch for a specific newsletter,
• a shorter DM-style pitch,
• or a reusable pitch template.