Who to hire

The pick when the buyer is an enterprise architect rather than a developer with a terminal open, and when the deliverable has to survive legal review. Long-standing subject-matter-expert model, human-written, with the process discipline that large accounts demand. Where they are least useful is the top of a developer funnel: quickstarts, sample apps and runnable tutorials are a different craft with a different rhythm.

The default answer when the constraint is volume of genuinely technical content and you have nobody in-house who can write it. Every piece comes from a practicing engineer in the relevant stack, which is the whole point: a tutorial written by someone who has never run the thing reads like one, and developers can tell inside a paragraph. Publishing the price and the minimum commitment is itself a signal in a category where most shops make you sit through a call to learn they start at five figures. Not the pick if what you need is positioning or a messaging rewrite: this is a production engine, and it works best when you already know what you want said.

An organic-growth shop with unusual credibility for developer audiences, because the people running it did the job inside GitHub and MongoDB first. They build the measurement layer alongside the content, which matters more than it sounds: most organic programmes fail at attribution long before they fail at writing. Take them seriously when search and answer-engine visibility is the bottleneck and you need someone who will argue about instrumentation. If your problem is that nobody understands what your product does, start with positioning instead.

Strategy first, words second. The house argument, right there in the book title, is that developer marketing works when it stops behaving like marketing, and the engagements follow from that: what developers need to understand before they will adopt, and what has to be true of your content for that to happen. The current three-part framing, LLM visibility then adoption then trust, is a fair reading of where discovery is heading. Hire them to decide what to publish and why. Hire someone with a bench to publish it at volume.

Broader than a pure content shop: docs and API references sit next to the tutorials, and the same team will run hackathons and paid media. They were early to name the machine reader as a distinct audience, selling agent-readable docs and GEO work as its own line rather than folding it into SEO. That matches where the evidence is going, and it is a reason to shortlist them if your docs and your content are the same problem with one owner. Ask which pieces the answer engines actually cite, and ask before you sign.

Built for the seed-to-Series-A devtool that needs a content function to exist by next quarter and cannot wait to hire one. Written, video and docs come from the same team, which is the practical argument for them: one brief, three surfaces. They measure themselves on API calls and SDK downloads rather than sessions, which is the correct instinct even if you should ask to see the dashboard. Push back on the publishing cadence if your differentiation needs explaining more than it needs repeating.

A small studio doing technical content, docs and, increasingly, the internal-knowledge work that decides whether either can be kept current. The interesting part of the offer is that they treat documentation and marketing content as one system rather than two departments, which is the right model for a startup where the docs are the funnel. Best suited to early-stage teams that want a partner in the work rather than a supplier of drafts.

The counter-argument to hiring an agency at all. For a team publishing two or three considered pieces a month, a single senior writer who learns your product properly beats a rotating cast of contractors, and the price of the two is closer than agencies would like you to notice. Essays and bottom-of-funnel comparisons are the strength here rather than volume tutorials. If your programme needs twelve pieces a month, this is the wrong shape and an agency is the honest answer.

The refusal to serve everyone is the selling point. A team that only works on devtools and infrastructure has argued about Kubernetes operators and data pipelines before, which shows up as fewer review cycles and fewer paragraphs that quietly say nothing. They will also do the unglamorous half, information architecture and the analytics plumbing, which is usually where a content programme is actually broken. Good fit for infrastructure products with a long, technical evaluation. Overkill if your buyer is a frontend developer with a five-minute install.

An operator who ran devtool marketing at a company with a real product, now selling the judgment rather than the hours. The homepage teardowns are the audition and they are free to read, so you can calibrate the taste before spending anything, which is more than most of this list allows. Best used as a second opinion on messaging and website copy at the point where your own team has stopped being able to see it. The newsletter is worth reading whether or not you ever hire him.

The unusual one on this list, because they will design and build the thing as well as position it. For a devtool where the marketing problem and the product problem are the same problem, the CLI is confusing, the onboarding loses people at step three, the launch has no artifact, that combination is hard to buy anywhere else. They also maintain enough open source to have standing with the audience you are trying to reach. Expect engineering-consultancy pricing and an opinionated team.

Where to go when the product is understood internally and nowhere else. The work is messaging and narrative for companies whose technology genuinely is complicated, and the deliverable is a structure your own team can keep using, not a deck that ages out in a quarter. Publishing the frameworks openly is the tell: an agency confident enough to give away the method is selling the judgment, which is the part you cannot copy. Engage them before you commission a content programme, not after it underperforms.

One of the few shops that will take the whole developer programme rather than a slice of it: strategy, demand generation, the developer experience work and the measurement on the end. That is the right shape when a company has decided developers are the buyer and has nobody senior who has done this before. It is the wrong shape when you already have a marketing team and need one specialist capability, because you will pay for the coordination layer you do not need.

Publishing the price ladder in public is rare enough in this category to be worth naming, and it makes the buying decision honest: you can see exactly what a first engagement costs before you book the call. The framing is pipeline rather than reach, which is the correct fight to pick with a CFO who has been handed a DevRel budget request. Right for a company standing up its first developer programme and needing someone who has done it inside a real API business.

Their signature engagement is a developer-experience friction audit: someone competent walks your onboarding as a stranger would and writes down every place it hurts. That is the highest-value week of consulting most devtools can buy, because the findings are specific, cheap to fix and impossible to see from the inside. The public artifacts, the book, the journey map, the annual report, are how you check the thinking before you spend. Buy the audit first and decide about a retainer afterwards.

The structural answer to the main complaint about DevRel agencies, which is that you meet the senior person in the pitch and then work with someone else. Here there is no intermediary to hide behind: you contract the individual, at their rate, for the specific slice of work you need, whether that is a launch, a docs overhaul or covering a parental leave. That also means no account manager chasing deliverables, so it suits a buyer who can brief clearly and manage a contractor. Worth watching as it fills out.

Matthew Revell has been arguing about what DevRel is for longer than most companies have had a DevRel team, and Hoopy sells that accumulated judgment as audits, strategy and training. The qualitative research offer is the underrated one: actually interviewing your developers about why they stalled, rather than inferring it from a funnel chart. Take them when the question is “is our developer programme working and what should it be”, and when the answer needs to survive contact with an exec team. Not the shop for staffing a conference booth next month.

Documentation as infrastructure rather than as content marketing: toolchains, information architecture, governance, and the automation that keeps a large docs estate from rotting. The embedded model is the one worth understanding, because a documentation engineer sitting inside your team for two quarters fixes causes rather than symptoms. Right for hardware, SDK and platform companies with sprawling surface area. Heavier machinery than an early-stage API needs.

The interesting bet here is the division of labour: agents run the mechanical passes, verifying every code sample against the live API, auditing links and coverage, while people decide what the docs should say and how they should be structured. That is roughly the right split, and it is the reason they can rebuild a documentation set in weeks rather than quarters. Treat the youth as the real risk and the speed as the real product. For a startup whose docs are three months behind the API, that trade is often worth making.

At a certain size a champions programme stops being a spreadsheet and starts being an operations problem: applications to triage, activity to track, contributions to reward, and an exec asking what any of it produced. This is the tooling for that, with people attached who have watched other companies do it. Relevant once you have more than a handful of advocates and no idea who is actually active. Premature if you are still deciding whether the programme should exist, which is a strategy question you should answer first.

The reference point for building a community deliberately instead of hoping one forms around a Discord invite. The engagements are strategy and coaching: what the community is for, how contribution ladders work, what to measure, and how to keep the thing alive when the launch enthusiasm fades. Useful when leadership has agreed to invest in community and nobody can articulate what success looks like. Less useful if what you actually need is someone to answer forum posts on Tuesday.

The buy-a-programme option for hackathons and developer events, at a scale no in-house team is going to replicate. What you are actually purchasing is repetition in front of people who will be making build-versus-buy decisions in three years, which is a legitimate strategy and a terrible one to justify on a quarterly dashboard. Sponsor it if your tool is free to start, genuinely fun to build with, and you can be patient. Do not sponsor it expecting attributable revenue.

Developer influencer marketing is a real channel now, and this is the operator layer on top of it: brief once, and they handle creator selection, production and the paid distribution behind it. The reason to use a broker rather than emailing YouTubers yourself is the boring part, contracts, briefs and consistent measurement across a dozen creators. The reason to be careful is that the audience punishes an ad that pretends not to be one harder than any other channel. Insist on visible disclosure and on creators who would use the product anyway.

The default source when someone asks how many developers there are in a segment and you need an answer with a method behind it. Population sizing and programme benchmarking are the two products that change decisions: the first stops you building a business case on a market that does not exist at that size, the second tells you whether your developer programme is average or actually good. Expect analyst-firm pricing. Read the methodology first, and treat every headline population figure, including theirs, as an estimate with a confidence interval attached.