Developers have spent a decade building defenses against exactly the message you are about to send them. Ad blockers, spam folders, a reflex to skim past anything that smells like marketing copy, and a shared habit of screenshotting bad sales emails for a laugh on a public timeline. None of that is unfair. It is a rational response to years of vendors treating a GitHub profile like a mailing list. The honest question for a dev tool startup is not how to write something clever enough to slip past that filter. It's which parts of getting customers the filter was never built to stop in the first place.
The filter isn't broken, it's aimed correctly
Send a generic pitch to an address you scraped off a commit history and you have not found a clever loophole. You have found the exact thing the filter exists to catch. Worse than being ignored, it can end up quoted, with your company name attached, in a thread full of the people you most wanted to reach. That is not a deliverability problem you fix with a better subject line. It is a signal that the message was aimed at the wrong person, which is the actual subject of this piece.
The person running your CLI and the person paying for it are often two different people
Plenty of dev tools start with free, individual adoption. Someone installs a package on a Tuesday afternoon because it solved a problem in front of them, with no purchase order anywhere near the decision. That person owes you nothing for having typed one command, and treating them as a sales lead for it is how a founder ends up in the screenshot.
The buyer shows up later, at the edge of the organization, when a team wants single sign-on, an audit log, a seat cap lifted, a security questionnaire answered, or a contract renewed. That person has a title attached to a budget line: a head of platform, an engineering manager, a director of infrastructure. They are an entirely ordinary business buyer, findable the same way any business buyer is findable, by company, title, and headcount. The mistake was never writing to a company. It was writing to whoever happened to run the install command, as though a free download made them the one who signs.
What actually earns a developer's attention, outbound cannot manufacture
Docs that answer a question faster than reading the source would. A changelog that tells the truth about what shipped and what broke. A free tier a stranger can try without filling out a form and waiting for a callback. None of that comes from a sending tool, and it is worth being blunt about it: if the docs are thin or the install is fussy, better targeting just gets more people to a bad first ten minutes, faster. That work sits with the founder regardless of anything else in this piece.
Where a loop still earns its place
Once a team is actually using the product and runs into a real limit, that is a signal worth acting on, and the moment to write is to the accountable person at that specific company, not to a stranger picked off a leaderboard of contributors. The message can reference the actual limit they hit, because it is true, not because it is flattering.
Speed matters more here than persuasion does. A technical evaluator who emails a pointed question is quietly testing whether this is a company that moves fast, and a three-day gap before the answer arrives has already answered that question, badly, regardless of what the answer eventually says. The same goes for the phone. Most weeks nobody calls a dev tool startup about anything, until the one week a security review is underway and someone from procurement dials the number listed on the site, expecting to reach an actual person. Having that call answered, recorded, and written down so nothing about it gets lost is a small thing that matters exactly once a quarter and matters enormously that once.
Sizing the list you can actually write to honestly
Rocketship will tell you, for nothing, how many companies fit that title and headcount band, and it will hand you twenty-five of the actual names to read before you decide whether the segment is real. For a dev tool, that number is the whole exercise: if the accountable buyer at companies your size runs into your category of problem only a few thousand times over, you have a list worth building slowly and correctly rather than a market to blast.
One credit puts a company into your pipeline. Locating a working email or phone number for the person there runs five credits, and the charge only lands on a hit, never on a search that comes back empty. Twenty-five dollars a month gets you Launch: one worker doing the writing and reading, one line picking up the phone, a hundred credits to spend, which at realistic account-based volume covers several dozen genuine companies rather than a few thousand scraped handles. Move up to Frontier at seventy-nine dollars once renewal conversations start needing a calendar slot instead of another email โ it doubles the worker count and adds the scheduler on top of a larger credit allowance. Mission Control triples the worker count again at a hundred and forty-nine dollars, and lifts the cap off how many apps you publish, well past what a dev tool startup needs before an actual sales hire is on payroll.
The part worth saying plainly before you send anything
If the plan is to cold-email individual developers pitching your API into their personal inbox, expect it to underperform, and read that as the market working correctly rather than as a tool failing you. That audience has earned its skepticism the hard way. What tends to work instead is quieter: a product that explains itself without help, a reply that lands inside the hour when a real evaluator asks a real question, and outreach aimed at the person who actually holds the budget once there is a genuine reason to write to them. None of that replaces the free tier or the two-minute install that got someone to try the thing in the first place. It just means that once a real account is ready to become a paying one, the message meant for the buyer reaches the buyer, and the phone gets answered the one week it actually matters.