LinkedIn outreach for dev tools founders.
Engineering buyers don't read cold email — they read LinkedIn DMs from the right people. The problem: most dev tools founders torch one or two personal LinkedIn accounts learning this.
LinkedIn's behavioral classifier catches naive automation within days. The signals it watches: connection-request velocity, profile-view patterns, residential vs datacenter IPs, and session timing. Founders who hit the platform with a single account and an off-the-shelf automation tool get connection-request limited within a week and account-restricted within a month.
What changes for this use case.
- ·Engineering audiences respond to LinkedIn DMs but not connection-requests with sales pitches — the surface matters.
- ·Dev tools ICPs cluster around specific OSS contributions, conference speakers, and Stack Overflow / GitHub signals. That changes the targeting model.
- ·The founder's personal account is reserved for warm intros and content. It never runs cold outbound.
From the knowledge base.
The chapters that map to this use case, in suggested reading order.
LinkedIn outreach — the infrastructure reference
Eight chapters. The full account architecture, detection model, and warming pattern.
Account architecture — why the founder's LinkedIn never runs cold outbound
The single most damaging LinkedIn mistake. Multi-account topology, role separation, and the reputation firewall.
The bot-detection model — what LinkedIn actually watches
Behavioral signals, IP residency, session timing. What gets flagged and why.
Messaging across the four surfaces
Connection-request messages, InMail, post-connection DMs, comment-based outreach. Per-surface conversion math.
First-party signal mining for ICP
GitHub, conference talks, OSS — the developer-audience targeting layer most generic outbound tools miss.
Multi-account LinkedIn, run as a service.
Account warming, residential proxies, persona accounts, the full messaging cadence. Operated end-to-end by an engineer in your Slack.