Outbound for developer tools

Two audiences, opposite tastes, one message

In most B2B software the buyer and the user overlap enough that one message serves both. In developer tools they diverge completely, and the divergence is not about seniority. It is about what each person considers evidence.

The engineering manager or platform lead who signs is thinking about cost, risk, onboarding and what happens when the vendor disappears. The engineer who will use the thing is thinking about whether it actually works, what it does under load, and whether it is another layer of something they will have to maintain.

A message written purely for the signer reads as marketing to the engineer, who then kills it quietly and without explanation. A message written purely for the engineer never reaches a budget. The message has to do both, which in practice means a technical claim expressed in commercial consequence: what the system does, then what that saves.

The veto is the part outsiders underestimate. In engineering organisations, a tool that the team dislikes does not get adopted no matter who bought it, and the purchase quietly lapses at renewal. Selling past the engineer produces a signature and no revenue twelve months later.

Bottom-up and top-down are different products

Developer tools companies routinely try to run both motions with one message, and the two are structurally incompatible.

Bottom-up means an individual engineer adopts the tool without asking anyone, and the account grows into a purchase later. This requires a free tier that is genuinely useful, self-service onboarding without a call, and documentation good enough to replace a salesperson. Outbound plays a small role here, mostly in converting existing usage into a contract.

Top-down means the organisation adopts the tool as a decision, usually because of governance, cost consolidation, compliance or a standard being imposed. This is where outbound works, and the message is about the organisation rather than about the individual engineer.

The failure is a bottom-up product sold top-down. The message reaches a VP of engineering, who asks the team, and the team has never heard of it and has no reason to want it. The reverse failure is a top-down product marketed bottom-up, where individual engineers try it, like it, and cannot get anyone to pay because the value only exists at organisation scale.

Decide which one you are before writing a sequence. The answer is usually visible in the pricing page.

Mechanism beats benefit

Ordinary B2B copywriting advice says to write benefits, not features. In developer tools that advice is actively harmful, because a benefit claim with no mechanism attached is the signature of a product that does not work.

Engineers evaluate by asking how. A message that says the product reduces build times says nothing checkable. A message that says it caches dependency resolution across branches so incremental builds skip a specific step says something an engineer can immediately assess against their own setup, and the benefit follows without being asserted.

This also solves the two-audience problem, because a mechanism stated plainly is readable by a manager as well. The manager reads it as specificity, which is a credibility signal at any level of technical depth.

The corollary is that vagueness is more expensive here than in any other category. Words like seamless, powerful, and platform are not merely weak, they are read as an attempt to avoid saying what the thing does.

The objection is always the same

Whatever the product, the first reply is a version of the same sentence: we already have something for that, or we built it internally.

This is usually true, and arguing with it loses. Every engineering organisation of any size has an internal script, a spreadsheet, an open source tool bent slightly out of shape, or a previous vendor. The tool exists. The question is what it costs to keep.

The productive response moves from capability to maintenance. Who owns the internal one. What happens when they leave. How much engineering time went into it last quarter. What it does not cover that has since become a requirement. None of those are arguments about your product, which is why they get answered.

Internal builds also have a predictable failure point: they work until the organisation grows past the assumptions they were written under. Approaching a company at the moment it crosses that threshold means arriving when the internal answer has already started failing, which is worth far more than any competitive comparison.

What counts as proof to an engineer

Not a logo, not a quote about a delightful partnership, and not a percentage without a baseline.

What works, roughly in order of strength:

• A reproducible benchmark with the methodology stated, including the conditions under which the result does not hold. Publishing the limits is what makes the rest believable.
• A public technical write-up of a real problem and how it was solved, whether or not it sells anything. This is the most durable asset a devtools company can own, and it does the selling before the outreach starts.
• Source or specification access. Anything a sceptic can inspect converts scepticism into evaluation.
• A named engineering team using it in production at similar scale, described in technical terms rather than as a customer story.

What actively damages credibility: invented metrics, comparison tables where the competitor column is obviously strawmanned, and marketing language applied to technical claims. Engineers detect all three quickly and the detection is permanent.

Triggers that precede a devtools purchase

Four observable changes reliably come before an organisation buying engineering software.

Crossing a team size threshold. Practices that work at eight engineers break at twenty-five and break differently at eighty. Each threshold creates demand for a category of tool that was unnecessary below it. Team size is visible from hiring, from public profiles and from engineering blog output.

A migration. Cloud provider, language version, framework, monorepo consolidation, or a move to a new deployment model. Migrations open every adjacent decision at once and are frequently discussed publicly by the teams doing them.

An incident. A public outage, a security disclosure, or a compliance finding moves budget faster than any pitch. Approaching immediately is tasteless and usually counterproductive. Approaching six to eight weeks later, when the retrospective actions are being funded, is timely.

A first platform or infrastructure hire. The first dedicated platform engineer means the organisation has decided that developer experience is somebody’s job. That person arrives with a mandate, an empty toolbox and a list of complaints from their new colleagues.

Channels, and where not to go

Email to engineering leadership works, at low volume and high specificity. LinkedIn works for the same audience with a lighter touch. The phone works less well here than in almost any other B2B category, because the audience treats an unexpected call as an interruption rather than an approach.

Three places to stay out of. Do not contact engineers through GitHub issues, pull requests or repository discussions. That space is not a channel and using it as one produces public, permanent, well-deserved criticism. Do not mine open source contributor lists for a prospecting database. And do not automate personalisation from a person’s public code, which reads as intrusive rather than attentive even when the underlying data is public.

The line is straightforward: a professional inbox is a reasonable place to receive a business proposal, and a shared technical workspace is not.

Measuring it honestly

Reply rate is a weak signal in this category, because engineering audiences reply less than commercial ones regardless of message quality. Two better measures exist.

The first is what happens after a reply. Devtools conversations that go anywhere almost always include a technical evaluation, so the meaningful conversion is meeting to trial or proof of concept, not first meeting itself. A pipeline full of meetings that never reach an evaluation is a message problem, not a volume problem.

The second is influenced self-service signups. In any company with a free tier, a share of outbound value shows up as an engineer quietly trying the product days after their manager received a message, with no attribution attached. Watching signups from targeted accounts, rather than replies from targeted contacts, captures a real effect that reply-rate reporting misses entirely.

We run outbound for technical products the way it needs to be run: small lists, real research, mechanism-first copy, and follow-up that respects how slowly engineering organisations decide. Flat pricing, 3,750 EUR the first month, then 2,850 EUR a month, cancel any time.