---
title: Cold email agency for developer tools
url: https://growthpal.io/developer-tools-cold-email-agency/
last_reviewed: 2026-10-23
source: growthpal.io
---

# Cold email agency for developer tools

GrowthPal runs outbound for developer tools, API businesses and infrastructure companies, where an engineer adopts the product and somebody else signs. Lists are built from what engineering teams publish themselves rather than from a language filter, and the first ask is usually a link, not a calendar. Best fit is past 3M in ARR, with an offer people already buy, a team ready to take calls, and roughly 30,000 reachable contacts.

## Who you are selling to

- **Founder or CTO, still technical** (). Cares about: Whether outbound can run without embarrassing the company in front of its own users. Has received a decade of bad vendor email and assumes outbound means that. Also whether the motion survives after the founder stops writing the emails. Best channel: Cold email to a personal work address, short, from a named person with a real profile. Replies to a specific technical observation about their product, never to a category pitch.
- **Head of Developer Relations or Developer Experience** (). Cares about: Community trust as a balance sheet item. Owns the docs, the SDK, the quickstart, the conference talks and the issue tracker. Measures adoption, not meetings. Best channel: Email that respects the line between the community channel and the sales channel, and proposes nothing being sent through a community channel. This is the person most likely to kill a program quietly.
- **VP Sales or the first sales hire** (). Cares about: Turning self-serve signups into contracts, finding the economic buyer above a happy engineer, and whether outbound can reach that person without cutting across the bottom-up motion that already works. Best channel: Email with an account expansion angle. They ask how adoption becomes a contract, not about open rates.
- **Head of Growth or growth engineer** (). Cares about: Signup to activation, time to first successful call, and where a second sourced channel comes from when docs traffic and search flatten out. Often writes code, so reads the mechanics of whatever you propose. Best channel: Email naming one measurable step in their funnel. Responds to a hypothesis that states its own failure condition.
- **Head of Platform Engineering, on the prospect side** (). Cares about: Build minutes, egress cost, on-call burden, and not adding a tool to a golden path they just finished standardizing. Not a GrowthPal buyer, but the person your campaign writes to, so the list schema has to hold them. Best channel: Short email with a link to documentation rather than a deck. They open the docs before replying, or instead of replying.

## What makes outbound different here

**The reader can decode the email, and publishes about it.** Developers run the tooling, read the headers, and recognize a merge tag, a spun opener and a generated first line. The honest position is that nobody has measured developer sentiment toward vendor email in a way that holds up: almost everything circulating is vendor content or anecdote, so we treat it as a design constraint rather than a statistic. What is measured is adjacent. In the Stack Overflow Developer Survey 2025, over 49,000 responses from 177 countries, distrust of AI tool accuracy outweighs trust, 46 percent against 33 percent, with 3.1 percent highly trusting.
_What it decides:_ The copy rules and the review step. No generated personalization, no false familiarity, and nothing in the email the reader could not verify in one click. Every email that names a technology gets checked against that technology's own documentation before it sends, because a misquoted version constraint ends the thread.

**The person who adopts is not the person who signs.** Bottom-up adoption means an engineer installs the package, uses the free tier and gets value before anyone speaks to sales. That engineer has no budget authority and no interest in a call. The budget holder above them has never seen the product and often does not know it is running.
_What it decides:_ Who gets emailed and what each one is asked. The engineer gets a specific, reversible ask: a doc page, a reproducible example, one endpoint. The budget holder gets a conversation about something already running inside their company. Both sit on the account row from the start, so the thread survives being forwarded upward.

**The ask has to be smaller than a demo.** A link to a documentation page, a working example, a benchmark with its method stated, a single endpoint to try. A calendar link asks for forty-five minutes from somebody who can evaluate the product in four, and it reads as a request to be sold to.
_What it decides:_ The sequence shape. The first email carries one link and the second carries a different one, so each step has its own reason to exist. Any step whose only content is a thread bump gets cut, because this audience reads a bump as filler.

**The richest sources here are governed by terms that restrict exactly this use.** GitHub's Acceptable Use Policies state that information from the service may not be used for spamming purposes, including sending unsolicited emails to users, and say that holds regardless of whether the information was scraped, collected through the API, or obtained otherwise. PyPI's Acceptable Use Policy carries the same restriction in the same words and adds an obligation to honor do-not-contact requests promptly.
_What it decides:_ How a row is built. Public repository and package registry data is used to understand an account and to write an accurate email, never as a source of addresses. The signal and the address are separate fields with separate provenance, and a row whose only contact source is a code host gets dropped rather than reassigned.

**Adoption is visible before the buyer is reachable.** Package downloads, dependency manifests, issue threads and release notes show a product spreading inside an account months before anyone with budget appears anywhere public. The signal is attached to the company, not to a person you can write to.
_What it decides:_ The list schema and the pacing. Evidence attaches to the account rather than to the contact, so the same proof can be used in two different emails to two different people. Accounts where only an engineer is reachable get a slower, lighter sequence, because there is nothing to escalate to yet.

## Buying triggers and the angle each one earns

| Trigger | How we find it | The angle | Proof needed |
|---|---|---|---|
| A license change, or the announcement of one | The LICENSE file in the public repository and its commit history, plus the project's own announcement post and the dated FAQ that usually accompanies it. HashiCorp's license FAQ, posted 10 August 2023 for its move to the Business Source License, is the reference example and states that the company views the guidance in it as binding. | Relicensing from a permissive license to a source-available one splits the user base into those who stay, those who fork, and those who now have to buy. All three become addressable at once. | The old license, the new license, the date, and which of the three groups the email is written to. |
| Package download trajectory changes | The npm download counts API, which is public, supports bulk queries of up to 128 packages and up to 365 days, and holds data back to 10 January 2015. For Python, the PyPI download data published through the Linehaul pipeline into the BigQuery public dataset of file downloads. | Adoption is outrunning the commercial motion behind it, so there are users inside accounts nobody has ever contacted. | The package name, the window compared, and an explicit note that the counts are noisy. The reader already knows that, so saying it first is the only way the number survives. |
| A dependency appears in, or disappears from, a public manifest | Public package.json, requirements.txt, go.mod and pom.xml files and their lockfiles in public repositories, plus deps.dev (Open Source Insights), a Google service covering Cargo, Go, Maven, npm, NuGet, PyPI and RubyGems and published as a BigQuery public dataset. An SBOM attached to a release carries the same information. | A team that just added or removed a dependency has made a build-or-buy decision in public, with a commit date on it. | The manifest file, the commit, and the dependency named correctly including its version constraint. |
| A public issue or discussion naming the problem you solve | The repository issue tracker and GitHub Discussions, plus the issue indexes at ecosyste.ms, which covers around 349 million repositories from roughly 2,000 sources and publishes its data under CC BY-SA 4.0. | Somebody wrote the problem down in their own words, with a timestamp, in a place they meant to be read. | The issue, quoted accurately, and an answer rather than a pitch. Replying inside the thread when you have nothing to add is the failure mode. |
| Repository activity concentrates on one maintainer, or goes quiet | The repository contributors and insights views, the public commit timeline, and GH Archive, which publishes the public GitHub event stream as hourly JSON archives and as a BigQuery dataset. | The project is carrying more load than the team behind it, which usually means commercial attention has moved or needs to. | The repository and one dated observation about activity, stated without implying the team is failing. |
| A job post that names the stack | Company careers pages, public Greenhouse and Ashby board URLs, and LinkedIn Jobs read manually. Platform, site reliability engineering and infrastructure postings routinely list the runtime, the orchestrator, the cloud, the CI system and the observability vendor by name. | The posting is a public inventory of what the team runs and what it is about to run, written by the team itself. | The exact role title, the posting date, and the two or three technologies the hypothesis actually depends on. |
| A conference talk or accepted session | Published conference schedules and speaker listings, which go public well before the event: KubeCon and other Linux Foundation events, FOSDEM, PyCon and most language conferences publish dated sessions with speaker name, employer and abstract. | The abstract states what the team built and what hurt while building it, in their own words, in public. | The talk title, the event, the date, and a question about the part the abstract says was hard. |
| A published incident retrospective | The company status page and its history or RSS feed, the published postmortem, and public architecture decision records where teams write up what they are changing next. | A postmortem usually names the component that failed and the work item that follows. The work item is the only part worth mentioning. | The postmortem, its date, and restraint. Using somebody's outage as a sales hook is the fastest route to being screenshotted. |

## Example angles we would test

Hypotheses, not results.

- Installs keep growing and nobody is working the accounts behind them, so revenue depends on engineers upgrading themselves. Proof: The package download trajectory over a stated window, with the accuracy caveat stated in the same sentence. Ask: Whether anyone works the accounts behind the installs.
- The license change split your users into stay, fork and buy, and there is no list for the third group. Proof: The LICENSE commit and the dated announcement post. Ask: Which of the three groups outbound reaches today.
- Engineers inside large companies sign up every week, and nobody reaches the person above them who signs the contract. Proof: A visible free tier plus a feature gated behind a self-hosted tier or a contract. Ask: How a signup becomes an account conversation today.
- Docs traffic and search have flattened, so growth now needs a second sourced channel nobody has built. Proof: The product's visible acquisition surface: docs, quickstart, community channels, and the absence of anything else. Ask: What share of pipeline is currently single-channel.
- Developer relations is being asked to produce pipeline, which puts community trust and a quota in the same budget line. Proof: A developer relations or developer advocate posting that names pipeline or qualified leads in the responsibilities. Ask: Who owns the line between the community channel and the sales channel.
- Your own outbound is being written by a tool, and your audience is the one audience that can tell. Proof: Something they published about their sending, or visible generated copy in their outbound. Ask: Whether the reply drop traces to deliverability or to the message.
- The conference talk named a problem you solved internally, and that problem describes a segment with no list behind it. Proof: The talk title, the event, the date and the abstract. Ask: Whether that segment is being prospected yet.
- Enterprise features exist, but the first ask is still a demo, so engineers who would have tried the product never enter the funnel. Proof: The quickstart and the pricing surface, showing where the contact-sales wall sits relative to the first working example. Ask: What the first ask is for an engineer rather than for a buyer.
- A dependency you replace is still sitting in the manifests of accounts that look exactly like your customers. Proof: The public manifest file and its commit date, with the dependency and version constraint named correctly. Ask: Whether those accounts are on any list today.
- Platform and reliability seats are being filled faster than pipeline is being built for the segment those seats serve. Proof: The public job board, with posting dates and the stack named in the postings. Ask: What covers pipeline while the seats ramp.

## How the list gets built

**Repository activity, read as signal only**

- Repository contributors, insights and release pages, for who is active and what shipped.
- GH Archive, the public GitHub event stream published as hourly JSON archives and as a BigQuery dataset, which gives dated activity at scale without crawling pages.
- ecosyste.ms, which indexes around 15.2 million packages from 110 sources and around 349 million repositories from roughly 2,000 sources, with commit, issue, sponsor and Dependabot indexes. Code is AGPL-3, data is CC BY-SA 4.0.
- Public issue trackers and GitHub Discussions, where the problem is already written down with a timestamp.

**Package registries and download data**

- The npm download counts API: public, bulk queries up to 128 packages and 365 days, data back to 10 January 2015.
- PyPI download data through the Linehaul pipeline into the BigQuery public dataset of file downloads, with package metadata in the companion table, both Creative Commons licensed.
- deps.dev (Open Source Insights), covering Cargo, Go, Maven, npm, NuGet, PyPI and RubyGems plus three code hosts, queryable in BigQuery through the Google Cloud Public Dataset Program.
- Download counts treated as a trajectory, never as a headcount. The Python Packaging User Guide states that PyPI does not publish counts on project pages largely because they are highly inaccurate, distorted by pip caching, mirrors and historical gaps.

**Dependency and build surface**

- Public package.json, requirements.txt, go.mod, Gemfile.lock, pom.xml and Cargo.toml files, and the lockfiles beside them, which pin versions exactly.
- SBOMs published alongside releases.
- Public CI configuration files, which name the runner, the cloud and often the observability vendor.
- Transitive dependencies read from the resolved graph rather than from the top-level file, because the interesting answer is usually two levels down.

**What the team writes, and where it hires and speaks**

- Release notes, public RFCs and architecture decision records.
- Status pages, incident history and published postmortems.
- Company careers pages and public Greenhouse and Ashby board URLs, where platform and reliability postings list the stack by name.
- Conference schedules and speaker listings, published with dates, employers and abstracts: KubeCon and other Linux Foundation events, FOSDEM, PyCon and the language conferences.
- LinkedIn for role and tenure verification only. LinkedIn prohibits scrapers, bots and automation extensions under its User Agreement and warns that accounts using them may be restricted, so it is a place to read, not a place to harvest.

**What makes a bad list here**

- Addresses lifted from commit history, git log output, AUTHORS files or package manifest author fields. The address was published so that code could be attributed, not so that a vendor could sell to the person.
- Anything assembled by scraping a code host or a package registry for contact data, which the GitHub and PyPI policies both address in writing.
- Maintainers of open source projects contacted because they maintain the project. The project is not a company, and the maintainer is often not paid for it.
- A list filtered only on a language or framework label. Every competitor bought the same filter from the same vendor.
- Download counts treated as adoption. PyPI's own documentation calls the counts highly inaccurate, and npm counts include mirrors, caches and CI runs.
- Role catch-alls: info@, hello@, support@, security@. The security alias in particular is watched by people whose job is to treat unexpected mail as hostile.
- An engineer and a budget holder merged into one persona, which produces an email asking an engineer to approve spend or asking a VP to run a quickstart.
- Rows whose signal came from a gated or private source that was described as public.

## A targeting brief for developer tools, in full

GrowthPal fills in the document below before a single row is built, and publishes it whole rather than as a screenshot, because the shape of it is the argument. Every field comes from a public source, read under the terms that govern it, before any call happens.

- **Audience**: Engineer or budget holder, chosen, not both in one campaign. If both are on the account, which one the first email goes to and what the second one gets instead.
- **Segment**: The stack, the runtime and the deployment shape: cloud, self-hosted tier, or both. Stated as what the team runs, not as a language label plus a headcount filter.
- **Signal**: The dated public event that earns the email: the LICENSE commit, the dependency added to a manifest, the issue thread, the job post naming the stack, the conference abstract, the status page postmortem.
- **Signal URL and permission**: The public URL the signal came from, and a note on whether that source permits this use. Repository and package registry data informs the email. It never supplies the address.
- **Address provenance**: A separate field from the signal, recording where the contact came from. Commit history, AUTHORS files and package manifest author fields are excluded, and a row with no other source gets dropped.
- **Signal age**: How old the signal is against your sales cycle. A relicensing announcement from two years ago is a fact about the company, not a reason to write this week.
- **The ask**: For an engineer: a doc page, a reproducible example, one endpoint, reversible in minutes. For a budget holder: a conversation about something already running inside their company. Not a demo, either way.
- **Technical claims to check**: Every product name, version constraint and benchmark in the email, with the documentation page each one was checked against. A misquoted version constraint ends the thread.
- **Disqualifiers**: Role catch-alls including security@, maintainers of unaffiliated open source projects, catch-all domains routed to a slower segment, prior opt-outs, existing customers, and duplicates against your CRM.
- **What would tell us this is wrong**: Written down before sending. A hypothesis with no failure condition teaches you nothing, because no result would ever count against it.

## Who this is not for

- **Before the product has users who stayed.** Outbound finds people with a problem you already solve. If engineers install the package and churn in a week, outbound will fill the funnel with more of the same and you will read a product result as a message result.
- **A market smaller than roughly 30,000 reachable contacts.** Some infrastructure categories are a few hundred teams who all know each other by name. Outbound still works there, but testing needs volume to separate a message that works from one that got lucky, so named-account research beats a system at that size.
- **No one ready to take the calls.** The first replies here are often technical questions from an engineer, sometimes within hours. If nobody who can answer a question about rate limits or self-hosting owns the follow-up inside a day, the interest cools and the spend is wasted.
- **Developer relations has not been consulted.** If the person who owns community trust first hears about the program when a user posts a screenshot of your email, the program ends that week. That conversation happens before launch, and it includes an explicit agreement that nothing goes through a community channel.
- **You want the list built from a code host.** We will not do it. GitHub and PyPI both state in writing that information from their services may not be used to send unsolicited email, and a maintainer emailed off a commit history is a story that travels further than any campaign.

## Questions

**Our users are developers. Will they hate this?**

Some will, and that cost is real rather than hypothetical. It gets managed by being narrow and boring: no generated personalization, no false familiarity, nothing sent through a community channel, a link to documentation instead of a deck, and an opt-out honored immediately. The honest caveat is that nobody has measured developer sentiment toward vendor email in a way that survives scrutiny. Nearly everything circulating is vendor content or anecdote, so we treat it as a design constraint, not a statistic.

**Can you build lists from GitHub or a package registry?**

Not as a contact source. GitHub's Acceptable Use Policies say information from the service may not be used for sending unsolicited emails to users, regardless of whether it was scraped, collected through the API, or obtained otherwise. PyPI's policy says the same and adds a duty to honor do-not-contact requests. What that data is good for is understanding an account: what it runs, what it just changed, what it wrote down. Addresses come from the company's own published channels and verified business sources.

**Will you email our maintainers, or anyone else's?**

No. An address in a commit, an AUTHORS file or a package manifest was published for attribution and bug reports. GitHub offers a noreply address and a privacy setting precisely because the visible address is an artifact of how git works. A maintainer contacted because they maintain a project is being contacted for a reason they never agreed to, and in open source that story travels a long way, fast.

**Do we email the engineer or the person who signs?**

Both, on the same account, with different asks. The engineer gets a specific, reversible ask: a doc page, a reproducible example, one endpoint. Asking them for a meeting wastes the touch, because they hold no budget and would rather read than talk. The budget holder gets a conversation about something already running inside their company. The account row carries both from the start, so the thread survives being forwarded upward.

**We already have bottom-up adoption and a free tier. What does outbound add?**

It reaches accounts your product cannot see, and the people above the engineers it can. Bottom-up gives you users with no path to the person who signs. Outbound here means two separate things: reaching the economic buyer above an existing user, and reaching accounts that resemble converted ones but have never signed up. Running a generic cold list alongside those usually dilutes both, so we pick one motion before a row is written.

**Can package download numbers be used as a buying signal?**

As a trajectory, yes. As a number in an email, no. The Python Packaging User Guide states that PyPI does not show download counts on project pages largely because they are highly inaccurate, distorted by pip caching, mirrors and historical gaps, and npm counts include CI runs and mirrors. Your reader knows exactly how the number is produced and will say so. A direction over a stated window, with the caveat said first, survives that scrutiny.

**What does the email actually look like?**

Short. Three or four sentences. One specific observation that could only have been written after looking, with the source linked or implied. One ask. One link, to documentation or a working example, rather than to a calendar. No adjectives, no company boilerplate, no second paragraph restating the first. The test is simple: if a line could be pasted into an email to a different company, it is a template and it goes back.

**When do engineers start trying the thing we pointed them at?**

First sends land two to four weeks after kickoff, once the sending infrastructure is warmed, and week eight is the usual point at which one angle pulls ahead. The caveat specific to this market is that week eight tells you about one audience. If the first eight weeks wrote to engineers, nothing in that result tells you how the same program would have performed written to the budget holder above them.

## Sources

- GitHub Docs, GitHub Acceptable Use Policies (primary). https://docs.github.com/en/site-policy/acceptable-use-policies/github-acceptable-use-policies (accessed 2026-10-23)
- Python Software Foundation, PyPI Acceptable Use Policy (primary). https://policies.python.org/pypi.org/Acceptable-Use-Policy/ (accessed 2026-10-23)
- npm Docs, npm Open-Source Terms (primary). https://docs.npmjs.com/policies/open-source-terms (accessed 2026-10-23)
- GitHub Docs, Setting your commit email address (primary). https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-email-preferences/setting-your-commit-email-address (accessed 2026-10-23)
- PyPI Docs, BigQuery Datasets (primary). https://docs.pypi.org/api/bigquery/ (accessed 2026-10-23)
- npm registry documentation, Download counts API (primary). https://github.com/npm/registry/blob/main/docs/download-counts.md (accessed 2026-10-23)
- Stack Overflow, 2025 Developer Survey (primary). https://survey.stackoverflow.co/2025/ (accessed 2026-10-23)
- HashiCorp, License FAQ (primary). https://www.hashicorp.com/en/license-faq (accessed 2026-10-23)
- Open Source Insights (deps.dev) documentation. https://docs.deps.dev/ (accessed 2026-10-23)
- ecosyste.ms, tools and datasets for open source. https://ecosyste.ms/ (accessed 2026-10-23)
- GH Archive, the public GitHub event stream. https://www.gharchive.org/ (accessed 2026-10-23)
- Python Packaging User Guide, Analyzing PyPI package downloads. https://packaging.python.org/guides/analyzing-pypi-package-downloads/ (accessed 2026-10-23)

Pricing is a fixed quote on a call, scoped to market size and volume.
No figure on this page is a guarantee of a result.