One of the most uncomfortable questions in the discipline of Developer Relations is: which developers are the right ones to spend time with? Not just any engaged developer, but the ones where your time compounds, where a good conversation leads somewhere meaningful for both them and for the business you’re part of.
Most DevRel practitioners know that meeting developers early, building trust before there’s any commercial reason to, and investing in people who are still students or early in their careers is genuinely valuable. The loyalty it builds is real. The problem is the timeline. That kind of investment might only pay off in several years, and in 2026, most companies operating with budget scrutiny and revenue pressure don’t have the runway to wait for it. That doesn’t make early-stage developer investment wrong, it just means it can’t be the whole strategy, and for most teams right now, it can’t even be the primary one.
Sales and marketing teams have spent decades building frameworks to answer exactly this question. One of the most practical is BANT, and it’s more applicable to DevRel than most people realize. I first got into this topic in a talk with John Booth at DevRelCon London in 2023, and it’s come up enough since that it felt worth writing down properly.
What Is BANT
BANT stands for Budget, Authority, Need, and Timing. It’s a qualification framework used by salespeople to figure out whether a prospect is worth pursuing. That framing might feel off for DevRel work, and that’s fair. But the underlying logic, that not all conversations are equally worth having, still applies.
The goal isn’t to filter out developers or treat community interactions as sales, but rather to understand context. The more you understand about why someone is talking to you, who they are inside their organization, and what they’re trying to accomplish, the better you can actually help them. That’s what makes BANT useful here: it’s a set of questions that simultaneously makes you more helpful and more intentional.
Authority: Who Is This Person, Really?
Technology decisions inside companies almost never come down to one person. A developer evaluating your tool is operating inside a web of stakeholders: a manager who owns the budget, a tech lead with strong opinions, and probably a procurement process waiting somewhere in the background.
When you’re talking to someone, it’s worth understanding where they sit in that web. Are they the one evaluating options? The one who’ll need to convince their team? The one who’ll maintain the integration long-term? All of those are worth helping, but how you help them is different.
The evaluator needs depth and honest tradeoffs. The internal champion needs materials and framing they can take into a room you won’t be in. The long-term maintainer needs to know what support looks like after the decision is made. Understanding which of these you’re talking to changes what a useful conversation looks like.
Done well, this means you stop being a resource the developer happens to find and start being an active participant in their decision process. You can equip them, anticipate what they’ll need next, and give them what they need to bring others along. That’s a fundamentally different kind of relationship.
Need: What Are They Actually Trying to Solve?
Developers rarely come to a DevRel interaction purely out of curiosity. There’s usually a project behind the question, a deadline behind the project, and a business problem behind the deadline. Understanding the actual need, not just the surface question, tells you how much this interaction matters and what good help actually looks like.
“How do I authenticate with your API?” is a question. But the thing behind it might be “I need to ship an integration by end of quarter and this is the last blocker,” which is a completely different situation requiring a completely different response.
It’s also worth understanding what happens if they don’t solve it. That tells you the urgency. And it’s worth knowing what else is competing for their attention, because the risk isn’t always that they choose a different tool. Sometimes the project just gets deprioritized and nothing happens.
Asking about need isn’t prying. Developers are generally happy to give context when they understand it’ll help you help them better. The question just has to come from genuine curiosity rather than qualification.
Timing: Where Are They in the Process?
Timing in a sales context means “when is the purchase happening?” That’s not quite the right question for DevRel, but a version of it is. When is the project shipping? Where are they in the evaluation?
A simple “when are you hoping to launch?” gives you an order of magnitude that shapes everything about how you help. Someone in early exploration needs different things than someone two weeks from a deadline. Detailed documentation and tutorials are great for the former. The latter needs you to answer one specific question, quickly.
Budget: Handle with Care
Budget is the one BANT element to approach differently as a DevRel professional. Asking directly shifts you from peer to salesperson in a way that’s hard to walk back, and it changes what the developer feels comfortable sharing with you going forward.
A softer version, something like “has budget been set aside for this yet, or is it still TBD?”, can give you useful signal without changing the nature of the conversation. In practice though, the budget conversation is usually better handled at handoff to sales. Your job is to arrive at that handoff with a warm, informed, and well-qualified developer. Let the salesperson take it from there.
The ICP: What Are You Qualifying Against?
BANT tells you how to understand an individual conversation. But you also need a picture of who you’re trying to reach in the first place. That’s the Ideal Customer Profile, or ICP.
An ICP is a description of the perfect customer for your product: company size, sector, funding stage, role, tech stack, the problems they’re actively trying to solve, where they go for information. It’s not a real person. It’s a composite target that represents the highest-value customer your company could acquire.
For DevRel, the ICP is what keeps your community-building directional. Without it, it’s easy to grow a large and genuinely engaged community that doesn’t produce much business value, not because the people aren’t great, but because they were never in a position to become customers.
With an ICP, you have a frame for every decision: what content to create, which communities to get involved in, which events are worth attending, which conversations deserve an hour versus a quick reply. It doesn’t mean ignoring everyone outside its parameters. It means being honest about where your time is most likely to compound.
One thing worth thinking through for each ICP is the full arc of their situation: what their world looks like before your product, what the cost of inaction actually is, what success looks like with your solution in it, and what the personal outcomes are for that individual specifically. The last one often gets skipped, but it matters. The developer who successfully champions a tool, ships a project on time, and walks into their next performance review with a story to tell has strong personal reasons to stay invested in that tool. Understanding their stake in the outcome helps you help them more effectively.
How This Connects to the Business
Being intentional about who you spend time with has a direct effect on two numbers that finance and leadership actually track.
Customer Acquisition Cost (CAC) is everything the company spends to bring in one new customer: salaries, events, content, advertising - and your time is in that number. Every hour you spend is effectively a line item in the calculation, which means how you allocate your time either compresses or inflates it. Spending time with developers who match your ICP and have real projects in motion moves CAC down. Spreading effort broadly across anyone who shows up moves it up. You don’t need to know every input in your company’s formula, but understanding roughly how it’s calculated tells you how your choices affect it.
Lifetime Value (LTV) is the total revenue a customer generates over their entire relationship with you. If your product is $10/month and the average customer stays 15 months, LTV is $150. That number sets the ceiling on how much you can afford to spend acquiring a customer. A healthy LTV:CAC ratio sits around 3-5x, and knowing where your company sits gives you a basis for making the case for larger, longer-term bets.
DevRel moves LTV in ways that often go unrecognized. Helping a developer go deeper into a product, bring colleagues onto the platform, or build something they’ll maintain long-term all extend that relationship. Good onboarding, strong documentation, a community where developers can get unstuck quickly: all of it contributes. If you have projects that span quarters, connecting them to LTV impact is usually the most compelling argument you can make internally.
If you don’t know your company’s LTV right now, that’s the first thing worth finding out. Anyone in sales leadership or finance will know it immediately.
Being Intentional Is the Point
None of this requires becoming a salesperson or letting go of what makes DevRel work: the authenticity, the peer relationships, the genuine investment in helping developers succeed. It requires being honest that your time is finite and that being strategic about who you spend it with is part of doing the job well.
The question isn’t whether to help developers who aren’t a fit. It’s whether the shape of your effort reflects where your time actually compounds. BANT and the ICP are just tools for making that clearer.
A question worth sitting with: does investing in early-stage or student developers increase their eventual lifetime value, given how sticky early tool exposure tends to be? The intuition says yes, and it’s probably right. But it’s a long-horizon play, and you can’t put all your effort there without sacrificing near-term results. The more useful framing is that you now have something measurable: track cohorts of developers you engaged early versus those you didn’t, and see whether the LTV difference justifies the investment over time. In the meantime, it’s a ratio question. Some portion of your effort on long-horizon relationship building, the rest on things that show return within a quarter or two.