The Winning DevTool GTM Stack, Based on 113 Companies
The Winning DevTool GTM Stack, Based on 113 Companies
Selling DevTools is hard, and choosing the right GTM stack is one of the hardest parts. We researched 113 prominent DevTools companies to see what solutions are actually being used to market software infrastructure. Here’s what we found.
Key Takeaways
- DevTools companies use a wide variety of GTM tools, with only four categories used by more than half: CRM, BI and analytics (76 per 100 companies with a CRM), marketing automation (67), and ERP and billing (57).
- The variety above that foundation reflects diverse GTM models. Some stacks are built around product data and a free tier, some around enterprise sales, and many companies run both.
- Even so, virtually every layer is dominated by a single vendor. Marketo is used by 99% of the companies that run marketing automation.
- Three capabilities are non-negotiable for every motion: a CRM, marketing automation, and agentic tooling to activate your data.
- PLG motions add behavioral analytics, identity resolution, and enrichment. Enterprise motions add call recording, intent data, and account discovery.
What Is a GTM Stack?
A GTM stack is the set of systems that move a customer from first signal to renewal. Traditionally it is split across four layers. Systems of record (CRMs, marketing automation, ERP, warehouse, and BI) store data. Intelligence layers (enrichment, intent, product analytics) add context. Activation layers (sequencers, routing, and agents) turn that context into action. Post-sale layers (support, customer success) help you keep the customer.
Why DevTools Often Need a Non-Generic Stack
The DevTools buyer journey is often more convoluted and less predictable and measurable. Developers will often avoid forms, use ad blockers, and generally try to evade any type of sales outreach you might throw at them. Their online footprint might look more like a PR made against your SDK, using your community version, or reading your migration guide. This requires a different approach to collecting and activating GTM data.
The difficulties don’t end there. Typically, the buyer doesn’t have budget authority, and budget authority tends to be disconnected from the technical expertise needed to evaluate your solution. Your GTM stack should help you close this gap, so that your GTM resources - SDRs, ABM campaigns, prospecting tools - are all aimed at the people who can actually move deals forwards.
What the Data Tells Us
We have strong opinions on DevTools GTM, but we wanted to consult the data. For this article, we analyzed job postings, LinkedIn profiles, and curated Onfire insights to see what companies are actually using day to day, looking at 113 prominent DevTool vendors with 500+ employees.
We used CRMs as a baseline (everyone has one) to see how popular other categories are in comparison.
The chart shows a fairly wide distribution. Only four categories, CRM, BI, marketing automation, and ERP and billing, are in use by over half of DevTools companies. The rest are diffuse, with quite a few used by less than a quarter of all companies.
This is what you would expect of a field that runs several GTM models at once:
- A company that grows through a free tier and open-source adoption builds the layer above its CRM around product data: the warehouse, behavioral analytics, enrichment.
- A company selling platform contracts to enterprise platform or security teams builds it around sales engagement, call recording, and account-based tooling.
Many DevTools companies run both plays simultaneously, so their stacks are combinations, and the combinations differ. Sales engagement tooling, for example, shows up at 25 percent of the companies we analyzed: outbound is one motion among several. Meanwhile, GTM job postings ask for data warehouse skills at seven times the rate current staff list them, which might be indicative of teams building PLG plumbing.
Even wit that variety, almost every layer has a default vendor: in two thirds of tool categories, one vendor shows up at 80 percent or more of the companies using it. Sales engagement (Outreach and Salesloft) and the warehouse (Snowflake and Databricks) are the main exceptions.
Adjusting Your Stack to Fit Your GTM
There are a few non-negotiables in DevTools GTM. Beyond that, the right stack depends on your motion. A PLG stack has to answer one question: out of thousands of pseudonymous users, which belong to an account worth a rep’s time, and when? An enterprise stack answers a different one: which accounts are in market, and who inside them would champion you? Many DevTools companies have to answer both.
Must-have capabilities
- A CRM to act as your source of truth. At scale that almost always means Salesforce, often with HubSpot alongside it. The vendor matters less than what you make the CRM hold. For DevTools, the account record needs fields a generic setup lacks: resolved product users, usage milestones, the stack in production, and the people who own the category you sell into. Make every other tool write to that record.
- Marketing automation to streamline lifecycle email and the handoff into sales. In DevTools the lifecycle starts before the signup (docs, a GitHub star, a package install) and runs through activation, a second user, a team workspace, so automation should be triggered by product events at each step. Then define the handoff: at what moment does a nurtured user become a sales-owned account, and what does the rep see when it happens?
- Agentic tools to activate your data (non-negotiable in 2026). Reps and RevOps now do much of their research through AI assistants, so prefer tools that expose an MCP server or a clean API. That lets Claude, ChatGPT, or an agent you build query the CRM, the warehouse, and your data providers together and answer “which accounts added seats this week, and who owns the platform team there?” with sources attached. A data-infrastructure company gave its SDRs 40 percent more selling time this way, with an agent doing the account research. This is different from an AI SDR that sends more email. The job of this layer is to change what your reps know before they reach out.
For PLG motions
If you run a PLG motion, add these three.
Behavioral analytics to surface PQLs. You need something that watches product telemetry against definitions you write and routes warm accounts to a rep when they cross a threshold. Good definitions are specific to your product: a workspace reaching three seats, a production API key issued, a second team adopting inside the same account. The threshold is a fit-plus-usage score you keep tuning. Scoring means joining product data with revenue data, usually in the warehouse, so budget for someone who can work there.
Identity resolution. Most DevTools signups are done with a Gmail address and a GitHub handle, so you need something that ties them to a company, and ideally to a person with a role. The signals are individually weak (commit email domains, public org membership, username reuse, session overlap), so confidence comes from stacking them, and every match should carry its evidence. If several tools resolve identity, they will disagree. Pick one system to own it and have everything else read from it.
Data enrichment. Once you’ve identified an account, you need to enrich it with size, stack, and funding to qualify it. For DevTools, the stack matters most and is what generic enrichment gets wrong most often, because technographics scraped from job posts are coarse and stale. Look for enrichment that infers the stack in production from a wider footprint (open-source activity, engineering blogs, what the engineers actually list) and that also names the team and the person who would own the decision.
For enterprise sales motions
If you’re selling to enterprises, add these three.
Call recording and conversation intelligence. When deals hinge on multi-threaded technical (and business) knowledge, you need to recover that institutional knowledge. In a DevTools deal, the calls carry what the CRM never will: which architecture the platform team is committed to, what the security review will ask for, who in the room deferred to whom. Feed that back into your buying-group map.
Intent data. Enterprises move slowly, so you need to know when an account is in-market before they tell you. Technical buyers leave little public trace of an evaluation, though, so third-party intent works best as a tiebreaker between accounts you already know are a fit.
Account discovery. Enterprise motions hinge on the quality of your target list, so you need a way to find the accounts that look like your best customers: the real stack in production, the size of the platform or security team, the hiring pattern. A publicly listed DevOps platform found 600 percent more accounts using a competitor’s product this way than through its reps’ manual Google searches.
If you run both motions, as most DevTools companies at scale do, make sure both sets of tools feed one account picture, so a free-tier user at a target enterprise shows up as a multi-threading lead.
How Onfire Fits in Your Stack
Identity resolution, enrichment, account discovery, and intent reading each produce a version of the account, and the stack only works if they agree. That’s why we built Onfire to be one system for that job rather than a hodgepodge of tools. It collects data on technical buyers that generic providers don’t have, ties the scattered and often pseudonymous signals into a single account intelligence graph (the real stack, the teams, and the decision owners), and shows the evidence behind each conclusion.
Onfire is also built for teams who sell software infrastructure. Forward-deployed engineers tailor it to your motion in days, and through the Onfire MCP connector your reps can query the account graph from Claude, ChatGPT, or any MCP-compatible agent.
Want to see what it finds for your GTM motion? Grab time with the team
FAQs
Why can’t DevTools companies use a standard B2B GTM stack?
Standard stacks assume the buyer identifies themselves by filling out a form. DevTools buyers evaluate through docs, repos, and free tiers, often anonymously or under a personal handle, and the person evaluating is usually not the person who signs the contract.
What is the minimum viable GTM stack for a DevTools company?
A CRM, marketing automation, something that can identify and enrich the accounts behind your product signals, and an AI agent that can query all three.
How do you identify the company behind a Gmail or GitHub signup?
By combining individually weak signals that point at one account: IP and network data, GitHub organization membership and commit history, package activity, session overlap with other users at the same account, and matching against known company records. No single signal is conclusive, which is why most teams buy this rather than build it.
Do PLG companies need intent data?
Less than enterprise sales teams do, because your own product is a better signal. API calls, seats added, and docs traffic tell you more about readiness to buy than any intent vendor can. Intent data becomes useful when you sell upmarket and need to see accounts before they touch the product.
.webp)
%20(1).webp)
.webp)
