Industry · Developer tools

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.

The buyer

Who you are really selling to

Role	What they care about	Where they pay attention	Best channel
Founder or CTO, still technical	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.	Hacker News, their own repository notifications, language and framework Discords, conference hallway conversation, a short list of engineering newsletters.	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	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.	DevRel communities, conference call-for-papers calendars, GitHub Discussions, package download graphs.	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	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.	Their own usage and expansion reporting, sales leadership communities, conversion dashboards.	Email with an account expansion angle. They ask how adoption becomes a contract, not about open rates.
Head of Growth or growth engineer	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.	Product analytics, their own funnel, technical growth writeups, open source adoption posts.	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	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.	Their issue tracker, their status page, internal architecture decision records, release notes from the projects they depend on.	Short email with a link to documentation rather than a deck. They open the docs before replying, or instead of replying.

Constraints

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.

Signals

Buying triggers, and the angle each one earns

Trigger	How we find it	The angle it earns	Proof the email needs
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.

Peek inside

Example angles we would test

Examples of angles to race in this market, not results. Each one is a hypothesis with its proof assembled before a single send.

Installs keep growing and nobody is working the accounts behind them, so revenue depends on engineers upgrading themselves.

Proof it needs: The package download trajectory over a stated window, with the accuracy caveat stated in the same sentence.
The 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 it needs: The LICENSE commit and the dated announcement post.
The 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 it needs: A visible free tier plus a feature gated behind a self-hosted tier or a contract.
The 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 it needs: The product's visible acquisition surface: docs, quickstart, community channels, and the absence of anything else.
The 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 it needs: A developer relations or developer advocate posting that names pipeline or qualified leads in the responsibilities.
The 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 it needs: Something they published about their sending, or visible generated copy in their outbound.
The 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 it needs: The talk title, the event, the date and the abstract.
The 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 it needs: The quickstart and the pricing surface, showing where the contact-sales wall sits relative to the first working example.
The 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 it needs: The public manifest file and its commit date, with the dependency and version constraint named correctly.
The 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 it needs: The public job board, with posting dates and the stack named in the postings.
The ask: What covers pipeline while the seats ramp.

The list

How the list gets built in this market

Engineering teams publish more about themselves than any other function. Manifests, issues, release notes, status pages, job posts and conference abstracts are written by the people who do the work and carry dates. Reading them is how the email earns its first sentence. None of them supply an address, and the section below is explicit about which half of the row each source feeds.

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.

How a row gets verified

Entity check: does the company still exist, still ship the product, and still run the stack the signal implied. Infrastructure choices move fast, and a migration post from last year makes a row stale.
Role check: is the person still in the role as of a dated source, and are they the engineer or the budget holder. Confusing those two is the most common reason a good angle lands wrong here.
Provenance check: every row records the public URL the signal came from and whether that source permits the use being made of it. A row whose only contact source is a code host or a package manifest gets dropped, not reassigned.
Trigger age check: the signal has to be younger than the sales cycle. A license change from two years ago is a fact about the company, not a reason to write this week.
Deliverability, suppression and dedupe: syntax, domain MX record, catch-all detection and a verification pass, with catch-all domains routed to a slower segment. Existing customers, prior opt-outs and a deduplication pass against your CRM are agreed before the first send.

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.

Rules

Compliance and trust constraints

Nothing here is legal advice, and platform terms change more often than law does. Read each source directly and confirm your own position with counsel before sending. The general rules, CAN-SPAM, UK PECR and the mailbox provider authentication requirements, are set out in full on the pillar and SaaS pages and are not repeated here. What follows is specific to this market.

GitHub's terms restrict using its information to send unsolicited email

Section 7 of GitHub's Acceptable Use Policies, Information Usage Restrictions, states that information from the service may not be used for spamming purposes, including for the purposes of sending unsolicited emails to users, or selling personal information such as to recruiters, headhunters and job boards. It says that applies regardless of whether the information was scraped, collected through the API, or obtained otherwise, and it defines scraping as extracting information via an automated process while noting that collection through the API is not what the word scraping refers to. The API route therefore carries the same usage restriction rather than an exemption. Section 4 separately prohibits automated excessive bulk activity and the relay of unsolicited advertising through its servers.

Read the source

PyPI says the same thing, and npm restricts how the site is accessed

PyPI's Acceptable Use Policy carries the restriction in near-identical language: information from PyPI may not be used for spamming purposes, including sending unsolicited emails to users, with the same scraping definition and the same note that API collection is not excluded. It also requires anyone collecting data from PyPI to respond promptly to complaints, removal requests and do-not-contact requests. npm's Open-Source Terms are separate from GitHub's policies: they permit replicating registry data through the publicly documented APIs, prohibit automating access to the website with a crawler, and state that five million requests to npm services in a single month-long period are under no circumstances reasonable.

Read the source

A commit-history address is not an invitation

GitHub provides every account a noreply address and a setting to keep email addresses private, and its documentation notes that whichever address is configured will be visible in any future commits pushed from the command line. The existence of that option is the clearest available signal that a visible address is an artifact of attribution rather than a contact method offered to vendors. An address in a commit, a package manifest author field or a maintainer listing was published so that code could be attributed and so that users could report problems with it. Using it for a sales email falls outside that purpose, and both policies above say so in writing.

Read the source

The actual document

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.

Field	What goes in it
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.

We publish the brief rather than a dashboard screenshot because a screenshot proves a number and a brief proves a method. Copying this means copying how we work, which is the point.

Process

How the engagement runs

Three stages and nine steps, the same ones in every market: build the list from public sources, race message angles against it, scale the one that wins. The nine steps from kickoff to booked meetings are written out in full.

What changes for this market

Week one settles the audience and the ask before a row is built. Engineer or budget holder, and what each one is asked for. The list source, the proof and the sequence all change with that answer, and a program that never decides writes to both badly.
The same week we agree the sourcing line with whoever owns developer relations: public repository and package registry data informs the email, never supplies the address, and nothing goes through a community channel. That is written down, because it is the commitment a user will test in public.
List building reads what the team published. Manifests and lockfiles, issue threads, release notes, status page postmortems, the job board with the stack named in it, the conference abstract. Every row carries its signal, the public URL it came from, and a separate field recording where the address came from and under what permission.
The send calendar is paced for short sequences rather than for volume: separate sending domains warmed before any send, no open or click tracking, and steps that each carry a different link. A step whose only job is to bump the thread gets cut before launch, because this audience reads a bump as filler.

Proof

What GrowthPal has published

GrowthPal takes on outbound engagements in this market, and the method above is the one it runs here. The published record below is the whole company record, across every client.

What was published	What the figure counts	Source
A study of 412 campaigns across 47 companies over 18 months: campaigns scoring above 0.7 on the composite message-market fit score averaged an 11.4 percent reply rate, against 1.1 percent for campaigns below 0.3. Volume, warm-up and time of day explained less than 8 percent of the variance.	Total reply rate, measured against messages in those campaigns. This is a different measure from interested replies per contact and the two must never be compared on the same page.	Read it
4M+ cold emails sent for 40+ B2B companies	Emails sent, cumulative across all clients. Not one campaign.	Read it

How these are counted

An interested reply means a human reply expressing interest in continuing the conversation. Out-of-office messages, unsubscribes, referrals to someone else and automated responses are not counted. A figure measured against contacts reached and a figure measured against emails sent are different measures: the column above says which each one is, and we do not convert between them or add them together.

The full counting method, and what an interested reply is.

On an industry-specific result. GrowthPal has not published a client outcome specific to developer tools or infrastructure, so this page offers the method instead: the public sources a list is built from, the terms that govern them, the verification passes, and the angles we would test first.

Honestly

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

Answered straight

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.

Who you are really selling to

What makes outbound different here

The reader can decode the email, and publishes about it

The person who adopts is not the person who signs

The ask has to be smaller than a demo

The richest sources here are governed by terms that restrict exactly this use

Adoption is visible before the buyer is reachable

Buying triggers, and the angle each one earns

Example angles we would test

How the list gets built in this market

Repository activity, read as signal only

Package registries and download data

Dependency and build surface

What the team writes, and where it hires and speaks

How a row gets verified

What makes a bad list here

Compliance and trust constraints

GitHub's terms restrict using its information to send unsolicited email

PyPI says the same thing, and npm restricts how the site is accessed

A commit-history address is not an invitation

A targeting brief for developer tools, in full

How the engagement runs

What changes for this market

What GrowthPal has published

How these are counted

Who this is not for

Answered straight

Related reading