DevTools

Why selling to developers requires a different signal model

Every DevTools company runs into the same paradox: the people who decide to use the product aren’t the people who write the check, and by the time the check-writer is in a procurement conversation, the developer has already decided. Cold outbound aimed at VPs of Engineering misses because it’s targeting the buyer who hasn’t yet been convinced. Cold outbound aimed at developers misses because developers don’t want to be sold to. The teams that scale revenue past the early-adopter cohort do it by letting developers decide quietly, then identifying which ones are ready to drag procurement along behind them.

That requires watching the right behavioral signal — and almost no DevTools company watches it well, because the signal lives in production telemetry that engineering owns and sales never touches.

The developer signal stack

When Beton looks at DevTools usage data, the patterns that consistently predict an account moving from “single developer playing around” to “team license needed” are surprisingly concrete:

• API key generation followed by code commits referencing the SDK. The moment a developer generates a key and writes integration code, the buying decision is effectively made. The procurement conversation will happen days or weeks later. If your team isn’t reaching out the moment that happens, you’re letting the AE walk into a deal they didn’t help close.
• Production environment markers. Most DevTools have implicit signals that distinguish dev/staging from production — TLS endpoints, organization domains in the auth context, request volume patterns. A developer crossing that line is signaling that the tool is on the critical path of something that ships to customers.
• CI/CD integration. A developer adding the tool to a build pipeline (GitHub Actions, GitLab CI, CircleCI) is committing the team’s deployment process to the tool. This is one of the highest-leverage signals because it creates organizational dependency, not individual preference.
• Multiple developers from the same email domain. Bottom-up adoption, by definition, spreads. The second user from a new account is more important than the first. Beton tracks that fanout pattern explicitly.
• Documentation deep-dives into enterprise features. The developer who reads the SSO docs, the audit log docs, or the on-prem deployment docs is doing recon for a procurement conversation. The team that spots that early gets to be in the conversation; the team that doesn’t gets to be on the receiving end of an RFP.

What the right outreach looks like

Selling to developers is mostly about not selling to developers. The outreach that works is contextual — it references the specific behavior the developer just exhibited and offers help, not a quote.

A Beton signal that says “developer at acme.com generated 4 API keys in the last 7 days, all hitting production endpoints, after spending 30+ minutes in the SSO documentation” enables an outreach like “hey, looks like you’re rolling [product] out across acme — happy to walk through the SSO setup or share how other teams structure team-level access.” That lands as helpful. “Would you like to upgrade to our Team tier” lands as creepy.

The role of the AE in DevTools sales is to be the developer’s internal advocate, not their adversary. Beton’s job is to give the AE the context to play that role at scale.

Where it fits in your existing stack

Beton sits on top of your product analytics — PostHog for most DevTools, occasionally a Postgres warehouse — and routes signals to whatever CRM your sales team uses. There’s no separate dashboard for AEs to remember to check. There’s no “developer engagement score” in a tool nobody opens. The signal lands as an account-level note in the CRM with the specific behavior the developer exhibited and a recommended next action.

Open source under AGPLv3 (auditable for the engineering-led companies that care about that), self-hostable, $0.50 per tracked user per month for the cloud version. Connect PostHog (or your warehouse), point it at your CRM, see signals in the workflow your team already uses.