How to Choose a DevRel Consultancy: A Founder’s Buying Guide

A founder I talked to recently was a week away from signing a six-figure DevRel retainer. He’d shortlisted three consultancies, had a deck from each, and a gut feeling about which one “got” his product. He hadn’t asked any of them what their operating model was. He hadn’t asked how they’d measure results. He hadn’t asked what they’d expect from him.

In other words, he didn’t have a clear idea on how to choose a DevRel consultancy.

That’s roughly how most of these decisions get made now. Type “DevRel strategy consulting for tech startups” into ChatGPT, take the names at the top, trust the deck. The trouble is the AI shortlist ranks consultancies mostly by SEO weight, not by whether they’re any good. And the quality range across DevRel consultancies right now is enormous. The buyer usually finds that out too late.

I’ve spent close to three decades in the developer ecosystem, and across that career I’ve worked with more than 250 developer-focused companies. Most of what follows is the stuff I wish founders and first-time Heads of DevRel knew before they signed anything: the four questions to ask on the call, what good scoping looks like depending on whether you’ve already got DevRel in-house, the contract clauses worth insisting on, and the blunt answer on when not to hire a consultancy at all.

The three ways a DevRel engagement goes wrong

Almost every failed engagement I’ve seen falls into one of three buckets.

Deck-and-leave. The consultancy shows up with a strategy deck, presents it beautifully, and disappears. Six months later your team is still staring at the PDF and nothing’s been built. There’s no operating model installed in the company, so the moment the consultant walks out, the engagement evaporates with them. There’s a wider pattern here. McKinsey’s State of Organizations 2026 found 72% of leaders say their organizations aren’t fully ready for the changes coming at them. Knowing the direction is not the same as being able to execute on it. A deck is direction. It isn’t execution.

Agency-with-no-strategy. They’ll ship things. Blog posts. Videos. Booths at every event with a developer track. None of it connects to a measurable outcome, because there isn’t one defined. You’ll feel busy and look busy and have nothing to show the board in month seven.

Embedded-but-undirected. A senior DevRel hire is already in place, the consultancy gets along great with them, everyone’s on Slack together, and six months in nothing actually moves. The DevRel hire thinks they’re doing a great job. The founder thinks the opposite. Neither is wrong, because nobody ever defined what good looked like. It’s a friendship, not an engagement.

Those three failure modes are why the questions in the next section matter. They’re not interview trivia. They’re how you screen out the consultancies whose default mode is one of the three above.

How to choose DevRel strategy consulting for tech startups: the four questions to ask on a Blind Spot Call

We call our intro call a Blind Spot Call, because the job of the first hour is to find the gap the team can’t see for itself. If you only ask one set of questions on any consultancy intro, ask these.

1. What’s your experience as a consultancy with DevRel?

The whole point of hiring a consultancy is to bring in people who’ve been there and done it, so they can show you what works, what doesn’t, and how to swerve the roadblocks that never show up in a tutorial.

Green flag: a team that’s done DevRel inside a lot of companies, at different stages, across different product categories.

Red flag: a consultant whose entire experience is one or two in-house tours of duty. One company’s playbook isn’t a playbook, it’s an anecdote.

2. What’s your operating model?

Green flag: a tested, named operating model that produces repeatable results. Ours is built on awareness, activation, and retention, with an iteration flywheel underneath, brand positioning up front, channel selection, developer influence hours as the awareness metric, and a Slack-plus-calls cadence so progress doesn’t wait on the next meeting.

Red flag: “we just get on calls and talk.” I ran that model for seven years and figured out the hard way that it’s flawed, because you never iterate, and iteration is where the value is. An operating model converts the consultant’s wisdom into something the company can actually run on its own. Without one, that experience never transfers. You can’t duplicate the consultant’s brain, so you install a way of working that captures it.

3. How do you generate and measure results, both output and outcome?

If you’re not measuring it, you’re not improving it.

Green flag: they answer in two parts. Output, meaning what gets shipped, how often, at what quality. Outcome, meaning the number that actually moves because of it. We track awareness in developer influence hours, and activation through three gates: interest to intent, intent to implement, and someone doing something useful with the product inside about ten minutes.

Red flag: they tell you which channels worked at their last client and skip the measurement question entirely.

You may be wondering what developer influence hours actually are. Fair question, because it’s something we came up with at Stateshift to solve a problem every DevRel team has: you can’t compare a conference talk to a blog post to a podcast in any honest way. It’s the metric we use to put every awareness channel on the same honest scale. Three inputs go in: how many of the right people you reached, how long they actually paid attention, and a quality weight for the format.

A 30-minute keynote to 100 ideal-customer developers is not the same as 10,000 random blog views, and the maths shouldn’t pretend otherwise. The point isn’t the exact number. It’s that you can finally compare a YouTube video, a conference talk, and a blog post on one dashboard, and decide what to do more of next week. We’ll break down how developer influence hours are calculated in a dedicated piece soon.

This question matters because most of the field struggles with it. The 10th annual State of Developer Relations Report (2023) found measurement was the top challenge for 67.3% of practitioners, ahead of every other obstacle. That number is a couple of years old. The problem isn’t. If most DevRel teams can’t measure their own work, a consultancy without a measurement model is the rule, not the exception.

This is also where we anchor everything we do. At Stateshift, the activation gates exist specifically to tie DevRel work to product adoption, not just awareness. We don’t count event attendance and community size and call it a result. We track whether someone moves from interest to intent, from intent to implementation, and on to actually using the product. A consultancy that can’t draw a line from its work to product adoption is one you should be wary of, no matter how good the activity looks.

4. What do you expect of me as a client?

Green flag: explicit, specific expectations of your time, your behaviour, and your accountability. This is a partnership, and there’s real work to be done on your side of it.

Red flag: waffle. Not every client is right for every consultancy. If you don’t hold up your end, there’s going to be a problem. The consultancies that won’t tell you what they need from you upfront are the ones that’ll quietly blame you for it later.

What good scoping actually looks like by stage

The scope should shift depending on stage, and specifically on whether you already have someone running DevRel internally. Most consultancies sell you the same package regardless. That’s the tell.

At Seed, with no DevRel hire yet. The job is to maximise the impact of the founder and the leadership team, and install the operating model so the company can run on it. Founders and execs should only ever work on the things only they can do. We worked with one company that had a CMO but no DevRel hire. We focused on implementing the operating model, selected the metrics worth tracking, put the channels with the biggest impact in place, and built AI agents to support that work so the team got maximum output from very limited time. Note what isn’t on that list: the founder writing blog posts.

At Series B, with a DevRel hire in place. The consultancy designs and installs the operating model. The hire then operates it. Our job is to teach that person how to run the model, so the founder is freed up to do the things only they can do. The model is the thing that stays behind when we leave.

At every stage, a healthy first 30 days inside a Stateshift Pathfinder engagement produces five concrete deliverables:

1. The engagement model goes live within the first couple of days: regular calls to clear roadblocks, plus an async Slack channel so work doesn’t stall between them.
2. The metrics dashboard goes live within the first week, covering both the ROI metrics that show overall program success and the performance metrics we use to iterate per channel.
3. Target audience and brand positioning are defined crisply, not dragged out over weeks of persona theater. If you don’t differentiate, you don’t stand out. If you don’t stand out, you don’t succeed.
4. Three activation gates get instrumented in something like Plausible or Google Analytics. This matters because awareness building means nothing if people land and leave before reaching value. Amplitude’s 2025 Product Benchmark Report, drawn from more than 2,600 companies, found over 98% of users churn within two weeks when they never hit a value milestone. All the awareness in the world will lose those people.
5. Channels are selected and producing. First assets ship inside the 30-day window so the per-channel performance metrics start flowing.

If you’re 30 days in and you don’t have those five things, the engagement is already off track.

The contract clauses founders should insist on

Most consulting scopes are written in vague terms. Conduct analysis. Provide recommendations. Support implementation. That vagueness is where engagements quietly drift and budgets quietly grow. The fix isn’t complicated. Insist on these in writing:

• A documented, named operating model. Not a call cadence dressed up as one.
• Explicit client obligations. Your time commitments, your team’s responsibilities, the decisions you’re on the hook to make.
• ROI metrics and performance metrics defined in week one, not month three.
• A written iteration cadence with performance reviews. If reviews only happen verbally, and only when something’s already gone wrong, they aren’t reviews.

Each clause maps to one of the failure modes above. Together they’re the difference between a real engagement and a glorified retainer.

When not to hire a DevRel consultancy at all

There’s a familiar argument going around that founders should run DevRel themselves until they hit meaningful traction, somewhere around the first 50 paying customers, and only bring in outside help after that.

I partly agree, but the gate is wrong. The real problem with bringing in a DevRel person too early isn’t the customer count. It’s hiring them before there’s a model for them to operate. Without one, the DevRel person does what they do for a year, and then the founder asks what they got for it, and the answer is a smattering of blog posts and a few events with nothing concrete behind them. The DevRel person thinks they did great work. It doesn’t match what the founder expected. That gap is the model’s absence, showing up a year too late.

So forget the 50-customers number. The gate that matters is whether an operating model is in place before you hire anyone. Founders should do the work only they can do: setting the vision, owning the market knowledge, putting the accountability and the metrics in place. Then hire people to operate that model. Writing blog posts and recording YouTube scripts were never on the founder’s list.

The thing underneath all of this

Every failure mode in this piece, and every clause worth fighting for in the contract, comes back to the same thing: an operating model. Most DevRel engagements don’t fail because the ideas were bad. They fail because nothing was installed for the company to run once the consultant left the room. Pick for that, scope for that, hire for that.

Common questions on how to choose a DevRel consultancy