Outbound by industry
Outbound for dev tool startups
Developers adopt tools bottom-up, but budget sits with an engineering manager or platform lead who answers one technical observation and ignores a sales pitch. Outbound for a dev tool is research first.
Who buys
The roles that sign, evaluate or veto when you sell as one of the dev tool startups.
Engineering manager
Feels the pain in sprint metrics and approves team-level spend without a procurement cycle.
Platform or DevOps lead
Owns the toolchain and the build pipeline; your tool must fit what is already there.
CTO at a company under about a hundred people
Decides alone and reads email themselves. One specific line about their stack gets a reply.
Head of developer experience
Exists at larger companies, measures adoption, and champions tools internally.
Which companies fit, and how to check
Four tests, each answerable from a public page before you spend anything on a contact.
| Test | Where to check it |
|---|---|
| It already uses the thing you integrate with | Job posts and the engineering blog name the framework, cloud, language or CI system. |
| It ships often enough to feel your problem | A public changelog with frequent entries, or an open-source repo with recent commits. |
| It has an engineering team of the right size | The careers page lists how many engineering roles are open and for which stack. |
| It is not already a customer of a direct alternative | The docs or the footer name the tool you replace, and the site’s integrations page lists it. |
Public buying signals to look for
Dated, quotable events on the prospect’s own pages.
| Signal | Page | What it can mean |
|---|---|---|
| A job post naming the language or tool you work with | Careers page | A dated, checkable fact about their stack, in their own words. |
| A public changelog or release notes | Changelog or docs | Release cadence shows build pain or its absence. Quote an entry, not a guess. |
| An engineering blog post about a migration | Engineering blog | A migration means evaluation is open. The post often states what they tried and why. |
| An open API or developer docs section just launched | Docs | A new developer program has needs: SDKs, testing, observability, docs hosting. |
| A status page with recurring incidents | Status page | Reliability work is on their plate. Mention the pattern only as they publish it. |
What to say
- One technical observation from a page of theirs, then one question about how they handle it today.
- Say which part of your tool is relevant and nothing else.
- Offer a link to docs or a repo only if the reader can use it without a call.
What to avoid
- Feature lists and logo walls.
- Calling developers a persona or a lead in the email.
- Fake familiarity with their codebase when you only read a job post.
A sample email
Every fact about the prospect sits next to the quote and the page it came from.
Illustrative. Larkspur Software (larkspursoftware.example) is an invented company, and so is Priya at Tracewell. The pages quoted do not exist. The email goes to its VP Engineering.
| What the email says | Quote on the page | Page (illustrative) |
|---|---|---|
| your engineering blog describes moving to a monorepo | “Last quarter we moved our services into a single monorepo.” | larkspursoftware.example/engineering |
| you are hiring a Platform Engineer | “Platform Engineer, build systems and CI” | larkspursoftware.example/careers |
Subject: The monorepo move at Larkspur
Hi {{first_name}},
Your engineering blog describes how you moved your services into a monorepo, and your careers page lists a Platform Engineer for build systems and CI.
Build times tend to be the first thing that hurts after a move like that. We make one narrow tool for finding which builds are slow and why.
Would it help if I sent a short note on what teams check first? Say no and I will leave it there.
PriyaOutlevo adds your sender name, postal address and a one-click unsubscribe link under every email it sends.
How Outlevo would run it
- 1
Read your site
It reads your own pages and drafts who you sell to, starting from tests like “it already uses the thing you integrate with” and “it ships often enough to feel your problem”.
- 2
Find and research
It finds companies that fit and reads each one’s own pages: careers page, changelog or docs and engineering blog.
- 3
Write with quotes
Each email says only what a page said, such as “your engineering blog describes moving to a monorepo”, with the quote and page kept beside it.
- 4
Send with limits
Addresses are verified, every email carries your opt-out line, and sending stops when bounces or complaints rise.
Go further
Selling to developer-tool buyers
The other side: the playbook for when you sell to this industry rather than from it.
Tech stack mention
A cold email template for a prospect whose job post or docs name a tool you integrate with: quote the line, talk integration, offer a small proof.
Hiring signal
A cold email template for when a prospect posts a role that signals a need: quote the posting, connect it to the problem, offer a small first step.
Every template
Cold email and AI prompt templates, each with an example.
Questions
Why not just let the product-led motion do the work?
What should I check first on a prospect’s site when I sell as one of the dev tool startups?
Outbound that quotes the prospect’s own pages
Outlevo reads your website, builds the ICP, researches each company and writes emails where every fact is quoted from its site.