Where to Find B2B Data for DevTools (and Why Most of it Sucks)
DevTools are among the fastest-growing segments in enterprise software, yet they’re incredibly difficult to sell. The simple fact is that most B2B data for DevTools sucks. Even science fiction-level AI struggles to identify the deep tech stack at potential accounts, pinpoint the prospects who sit on a buying committee, or pick up on the signals that indicate someone is in-market.
This article lays out how to find the data that makes a difference for software infrastructure GTM.
Key Takeaways
- The data you need for DevTools GTM is mostly non-public or requires inference.
- Job titles are a bad proxy for problem ownership. "Platform Engineer" at one company owns the CI pipeline; at another, the same title means Terraform modules and nothing else.
- AI agents are good at finding public info, but they can't crawl most social platforms and get expensive fast at scale.
- The combination that works is first-party plus technical third-party data, resolved to the same accounts and people, and made available to the agents your team already uses.
The Problem: Technical Buyers Act Different
Unlike the generic business buyers that traditional B2B motions are built for, developers don’t fill in forms or download white papers. Instead of booking a demo, they simply install software and try to use it themselves.
Yet that doesn’t mean they’re invisible. In fact, your typical engineer leaves quite the digital footprint as they contribute to OS repos, argue in Discord servers, and leave comments on Hacker News. So to find technical buyers, you simply need to look in different places.
The data that matters for DevTools
- Technographics: Typically, this means deep tech like the orchestration layer, the CI/CD system, the observability vendor, the cloud posture, the database, and the language runtimes.
- OSS adoption: Few things can tell you as much about an account’s architecture, maturity, and preferences as their OS activity.
- Product usage signals: Your first-party data, ranging from trial signups and docs traffic to sandbox activity and free-tier accounts, gives you reliable (and proprietary) insight.
- Community activity: Engineers argue about what they care about, making dev-centric forums an essential source of revenue intel.
- Problem ownership: Problem ownership is not the same as your job title. A “DevOps Engineer” at a startup might own the whole prod environment, while the same position at a bank will own a single process. To start talking to the right people, you need to figure out who owns a given problem.
- Standard sales intel: You can’t forget the basics, and phone numbers, firmographics, and job postings are still must-haves.
Why this data is hard to find
If you’re selling software infrastructure, you already know this data is hard to find. Most of it is non-public, so even advanced AI can’t access it. Moreover, you have to make a fair amount of inferences to jump from a GitHub issue about instrumentation overhead to the conclusion that an account is evaluating replacements for its APM vendor.
And then there’s identity resolution, which is a data science challenge in its own right. To connect a GitHub handle, a Reddit username, a conference badge, a work email, and a CRM contact record, you have to stitch together five separate identities into a concrete individual. That either takes months of GTM engineering work or a purpose-built solution.
Where Can You Find B2B Data for DevTools?
For some types of DevTool GTM data, you can use a general AI agent. Yet others are harder to find. Here’s how it breaks down:
1. AI agents
Agents are actually pretty effective for data that’s publicly accessible. They can automate all the tedious Googling and summarizing that used to be a chore for just about every BDR. Rather than reading company blogs or reviewing GitHub repos, you can simply offload that work to an agent.
Yet there’s a bunch of information that agents, for all their computational power, simply can’t access. That includes:
- Non-public data, like what’s in a CRM, a call transcript, or the accounts in your free tier.
- Most social platforms, which are purposely closed to crawlers. To see a technical conversation unfolding on X, Reddit, Discord, or Slack, you can’t rely on a general-purpose agent.
Agents have other downsides, too. Deep research on hundreds of accounts will quickly drive up costs, and sadly, you’re paying to re-research the same context each time you refresh because none of it persists. And since LLMs aren’t deterministic, your reps will get different answers each time they search.
2. AI agents + Onfire
Agents are great at execution, but they need data. That’s what Onfire provides. Onfire’s Account Intelligence Graph is built from over 100,000 sources to deliver the technographics, open-source activity, and community signals that drive efficient GTM. And because we fine-tune it to pick up on the data that’s relevant to your ICP, it interprets this data in light of your GTM motion.
The platform then de-anonymizes and resolves everything it finds to real people at real accounts so your humans (or agents) know who to contact, when, and why. And because
Onfire’s data includes your first-party systems, like your CRM records, trial signups, product usage, and sales notes, it gives you a complete picture of each buyer.
The Onfire MCP then connects that picture to your agents, which get the resolved graph, your CRM, and your unique ICP configuration. Armed with that info, they can write to your CRM, trigger alerts, and enroll accounts in sequences.
3. General-purpose revenue intelligence tools
If you want to drive DevTools GTM with generalist revenue intelligence tools, you’ll likely need to stitch a combination of multiple solutions together with a DIY orchestration tool. Yet we’ve found that even a rather complex stack will still leave you with blind spots:
Data providers (Apollo, ZoomInfo, Cognism): These legacy tools are great at compiling the things they were built to find: firmographics, contact records, org charts, and direct dials. Yet they’re weak at technographics, which are typically inferred from job postings and web scripts that miss the deep tech insights that drive software infrastructure sales. And since these records don’t connect to your proprietary data, you get a long list instead of a prioritized selection.
Intent data platforms (6sense, Demandbase, Bombora). By inferring interest from web activity, IP matching, and publisher co-op content consumption, these platforms give you genuine insight into generic B2B buyers, who consume industry publications and vendor comparison pages. Yet technical buyers steer clear of all that, focusing instead on repos, forums, and community channels.
DIY agentic tools (Clay). Workflow orchestrators are impressive in their own right, but they can’t create data they don’t have access to. They face the same constraints as agents who can execute complex sequences based on legacy info and web search, but with the added overhead of maintaining a fairly technical flow as your stack evolves.
In summary:
Find Useful DevTools GTM Data Using Onfire
Most B2B data is bad for DevTools because it was collected with a different buyer in mind, and while AI agents are impressive, they can only work with what they can see. To really benefit from an agentic workflow, give your AI the intelligence tuned to your technical-buyer ICP. See how Onfire finds the DevTools data others can’t.
FAQs
1. Why are technographics so inaccurate for developer tools?
Because of how they're collected. Most providers infer a company's tech stack from two sources: scripts loaded on the public website, and technologies named in job postings. The first only sees the front end. The second reflects what a recruiter wrote, which may describe a team that hasn't been hired yet, or a stack that changed two years ago. Neither observes what's actually running in production.
2. Can I just use ChatGPT or Claude to research accounts?
For public information, yes, and it's a meaningful improvement over manual research. An agent can read an engineering blog, public repos, job postings, and conference talks, and give you a usable brief in minutes. What it can't do is access your CRM and product data, reach community platforms that block crawlers, or retain what it found so the rest of the team benefits. It's a research assistant, not a data layer.
3. What's the difference between job title and problem ownership?
A job title is what a company chose to call a role. Problem ownership is who's actually accountable for the thing you sell into. Engineering titles vary wildly between organizations, so title-based targeting produces a list of people who might be relevant. Behavioral evidence, such as who filed the issue, who maintains the repo, who spoke about the problem publicly, and who's on the on-call rotation, identifies the person who is.
4. How does first-party data fit in?
It's usually the most accurate data a DevTools company owns, but it’s typically the least used. Trial signups, docs visits, SDK downloads, repo activity, and free-tier usage tell you which accounts are already touching your product. On its own it's incomplete, because it only covers people who found you. Combined with third-party technical signal, it becomes prioritization: which of the accounts showing intent in the wild already have a foothold in your product, and which are still cold.
.webp)
%20(1).webp)
.webp)
