Startups don't need DevRel. A debate.
Stefan Avram's tweet said startups shouldn't hire DevRel — their customers should be the DevRel. Dan Moore, head of DevRel at FusionAuth, wrote a blog post arguing he was wrong. Get them on a call together, though, and the actual disagreement turns out to be much narrower than either the tweet or the rebuttal suggested.
Stefan Avram is co-founder and head of growth at WunderGraph, an open-source GraphQL federation company. Dan Moore is head of DevRel at FusionAuth, an identity server company.
Jack invited them on after Stefan's tweet, 'you shouldn't have DevRels, your customers should be your DevRels,' prompted Dan to publicly disagree. Rather than a straight Q&A, here's how their actual positions broke down and where they landed.
The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.
Stefan's opening position — what did the tweet actually mean?
Stefan admitted he'd forgotten the tweet's exact wording by the time he came on, which says something about how spicy takes work on Twitter — a genuinely useful tip gets ignored, but a provocative one-liner gets thousands of views. The claim was roughly: you shouldn't have DevRel, your customers should be your DevRel. Once pressed, Stefan immediately narrowed it: he should have prefaced it as being about early-stage startups specifically, like WunderGraph, which at the time was around 14 people, every one of them a developer, including Stefan himself, who no longer really codes because he's fully absorbed into sales, marketing, and growth. At that size, everyone is focused on educating the market directly, tweeting about what they're building, and talking to customers — and since WunderGraph is open source, customers already help maintain and extend it.
Dan's rebuttal — where does he actually disagree?
Dan's first move was to set the terms: he wanted to constrain the conversation to VC-backed startups rather than huge companies, and from there, he agreed completely that every company should have its customers acting as advocates — there's far more credibility in a customer saying WunderGraph solved their problem than in WunderGraph saying it about itself. His actual objection is narrower: customers are busy, and they should be, because they're using your tool to solve their own problems, not yours. It's great when a customer writes a blog post, testimonial, or contributes open-source code, but if you rely on customers to do everything a functioning DevRel department does, you'll be pleasantly surprised at best — because customers won't do the grind work: detailed documentation across all four Diátaxis categories (reference, tutorials, how-tos, and explanation), maintaining complementary open-source libraries with a coherent long-term vision, or flying out to speak at conferences and meetups on your behalf. That awareness-building work is what a properly structured DevRel function actually adds.
So where did they actually converge?
Almost immediately. Stefan clarified his real claim was that founders should be the early DevRel, not that DevRel as a discipline is pointless — and Dan agreed completely, drawing the same parallel to founders needing to be early salespeople and early customer support. At his own earlier startup, before FusionAuth, Dan personally did customer support calls, product, and QA as the technical co-founder, because no hire will ever have a founder's level of passion for taking something from zero to one. Both agreed that hiring an expensive, big-name DevRel hire early is usually a mismatch: Stefan described WunderGraph being pitched a $290k/year candidate with 100,000 Twitter followers right after raising a $3 million seed round, and choosing instead to have the founding team be the DevRel function. Dan referenced a video by Jonan, former head of DevRel at New Relic, distinguishing a big-name hire from someone scrappier and hungrier — Dan's ideal early DevRel hire is a software engineer at the company already, interested in shifting toward marketing and sales, and willing to be a utility player, since a 14-person company can't afford anyone who isn't.
What was Stefan's argument against hiring a big-name, high-follower DevRel early?
At the early stage, you're still finding product-market fit and experimenting with what the product actually is. If someone with 100,000 followers and heavy Twitter reach starts talking publicly about your product and then the product pivots direction, it reads as untrustworthy — 'wait, I thought they were doing this SDK, now they're doing something else' — and the bigger their following, the more that inconsistency can actively hurt you rather than help. Stefan told a story about a similarly funded competitor that hired two DevRels with large followings — one around 60,000, one around 10,000 — both of whom eventually left as the company pivoted away from GraphQL entirely, one to databases, one to an ORM. His deeper concern was about audience match, not just follower count: he'd rather hire a DevRel with 2,000 genuinely relevant GraphQL followers who are trusted by the right enterprises, than someone with 50,000 followers of unknown composition — junior developers, decision-makers, or people who just liked a comedy show once.
Dan's response to the audience-match point — and his broader worry about hiring DevRel as a silver bullet
Dan agreed and extended it: hiring someone with a big following is like buying a Super Bowl ad — it might bring a ton of traffic, but you might not be equipped to appropriately handle what shows up, whether that's bugs surfacing at scale or gaps in the funnel. He also noted that a hire without an existing big name tends to have more loyalty to the company that took a chance on them, versus someone who has plenty of other options and is essentially choosing among many employers. More broadly, Dan pushed back on a trend he thinks has faded somewhat in the last couple of years: the idea that hiring a DevRel person makes all your other problems disappear, like magic fairy dust. He doesn't think that's true, and considers DevRel one important function among several, not a category that transcends the normal difficulty of making a startup work.
Why does Dan think DevRel exists as a distinct function at all, rather than just being sales or marketing?
Developers have a few unusual traits as a buying audience: they're allergic to marketing, they often start out using things for free, the buying process for dev tools is unusually involved, and the product tends to be far stickier once adopted, since it gets embedded into what they build. That combination is why Dan thinks 'developer relations' is genuinely distinct — he's never encountered an equivalent 'accounting relations' or 'food relations' function at other kinds of companies. On where DevRel should sit organizationally, Dan has seen it live in product, marketing, sales, or reporting straight to the CEO, which is the current setup at FusionAuth. His view is that especially at an early-stage company, DevRel should be cross-functional, and folding it fully into either marketing or sales short-circuits some of its value — he sees his own role as being the voice of the community: people who pay not in dollars, but in attention, mindshare, bug reports, and suggestions, which can't pay a mortgage directly but can vastly improve a product's chances of success.
Stefan pushed back that DevRel is really sales dressed up as education. How did that resolve?
Stefan's frustration is with DevRel people who insist their job is purely to educate, when the actual point of education is to move a potential user toward becoming a potential buyer who eventually pays. He gave an example of a DevRel at a large web-hosting company publicly claiming a tool couldn't be used with Vite and that you had to use their own company's turbo repo instead — only for someone to correct them in the comments, since it clearly was possible. To Stefan, that's a tell that the DevRel's real function was sales, not education, since a genuinely educational answer would have laid out both options honestly. Dan agreed this identifies a real tension, one that shows up in most roles at a company to some degree: you need to maintain credibility and integrity with developers, but you also need to recognize someone's paying your salary because the company needs to make sales. His own resolution is to say, honestly, when a competitor is a better fit for someone's specific situation — he's recommended AWS Cognito over FusionAuth when someone is tightly tied into the AWS ecosystem and doesn't need FusionAuth's extra features — while still making the case that outsourcing authentication to some dedicated tool, whichever one, usually beats building it yourself. A good DevRel should openly acknowledge a competitor working well in a specific case; failing to do that, in Dan's words, just makes you a highly paid public sales engineer.
The conversation turned to disclosure and incentives. What was that about?
Stefan raised a personal example: a friend recommended a vitamin subscription enthusiastically, and Stefan later discovered the friend was an affiliate earning money per signup — which retroactively made him question whether the recommendation was genuine. He drew the parallel to tech influencers quietly sponsored by companies like Vercel without disclosing it, and to DevRel more generally: would you still be talking about this product if you didn't work there? Dan's answer was that he wouldn't be talking about FusionAuth nearly as much if he didn't work there, but the actual issue isn't the incentive itself, it's the lack of disclosure — being upfront that you're being paid, or getting a cut, lets someone factor that into their own judgment rather than feeling secretly misled. Dan says he's about 98% consistent about disclosing he works for FusionAuth whenever he comments on identity topics on Hacker News, and frames the underlying dynamic as a choice between maintaining social capital and mining it — quietly monetizing your credibility for short-term gain at a long-term cost, the way undisclosed multi-level-marketing-style promotion does.
Stefan mentioned a customer case study that moved him. What was the point of that story?
Stefan described nearly tearing up reading a customer case study WunderGraph had just published, because the customer spoke about the product with genuine passion despite having no financial tie to WunderGraph beyond being a paying user — WunderGraph pays no one to say this. He compared it to recommending Superhuman to friends unprompted, purely because it makes email genuinely enjoyable, with zero affiliation. His point: unbiased word-of-mouth like that is the best possible form of DevRel, and it's part of why he believes you may not need a dedicated DevRel hire very early on if the product itself is generating that kind of unprompted advocacy. Dan's addition was that while every company should aim to build something people are that excited about, some categories make it easier than others — email is universally relatable in a way a GraphQL server or auth server may not be — and that early-stage DevRel adds real value precisely in the parts of the funnel that aren't about awareness: the friction that costs you users after they've found you, when the documentation is bad or the onboarding experience doesn't work.
How did each of them summarize their advice for early-stage founders?
Stefan's team focuses heavily on detailed blog posts written by the founders themselves, describing specifically what they're building, plus writing up interesting things customers are building with the product. SEO is a six-month game — a post written today might take that long to start bringing meaningful traffic — and Stefan credits the 80/20 rule: roughly 80% of WunderGraph's success has come from 20% of their effort, concentrated on Twitter, blog posts, and YouTube, after trying everything else. Dan's closing advice: early-stage founders should be the DevRel. If you do decide to hire, hire a software engineer already at the company, or one interested in the space, who's shown some aptitude for writing or speaking — not a 'LeBron James of DevRel' brought in from outside. And DevRel needs structure and an actual working product behind it; it isn't magic fairy dust that solves product-market fit problems on its own.
Links & references
This episode is brought to you by WorkOS.