17 Lessons from DevGTM experts on marketing to developers
Learn 17 practical lessons on marketing to developers from DevGTM experts at PostHog, Mozilla, GitBook, Hackmamba, and more.
Developer marketing has always existed. Nobody just knew what to call it. Guy Kawasaki coined "technical evangelist" at Apple in 1984. Steve Ballmer formalized the role at Microsoft in 1987. The job was simple: find people who believed in what you were building and get them to spread the word.
AWS showed what this looked like at scale. On March 14, 2006, it launched S3 with a one-paragraph announcement and no demo, just a simple API that handed any developer the same storage infrastructure Amazon ran on, billed to a credit card. 12,000 developers signed up on the first day. There was no campaign and no sales team behind it. The product worked, and the people using it told everyone else.
Those 12,000 signups were the whole lesson. Nobody in that group sat through a procurement cycle or a sales pitch. They found a tool, put in a card, and started building, and the company they worked for picked up the decision after the fact. Sell to the engineer and the organisation follows.
Twilio, Stripe, SendGrid, Okta, Plaid, and Algolia built entire companies on that bet. They skipped the boardroom and went straight to the people writing the code, with free tiers, documentation, and APIs you could try in an afternoon. A tool would start on a side project, find its way into production, and the invoice landed long after engineering had already decided it could not live without it.
Developer marketing now stands as a complete practice of its own, regardless of whether your go-to-market motion is product-led, sales-led, or community-led. Companies need experts, agencies, and consultants dedicated entirely to reaching this audience, earning their trust, and growing with them.
I spent close to two years in SaaS marketing, consulting for companies like Atlan, Hasura, Vymo, and Everstage. I thought I understood how marketing worked. Then I made the switch into developer tools last year and realized I had to relearn almost everything. Marketing is hard. Marketing to developers is a different kind of hard.
So I went and asked the people who have been doing this longer than me. I reached out to eight DevGTM practitioners and asked them to share what they had learned from years of marketing to developers. Under each lesson I have added my own two cents, plus an example where there is a good one to point to.
Here is what they said. But before that, let me introduce the people who took the time.
Meet the 8 experts
1. Joe Martin - Marketing Lead at PostHog | LinkedIn
Joe joined PostHog as the first and only marketing hire when the company was just an analytics tool. Five years later, PostHog is valued at over $1.6B and Joe leads the full marketing team. A recovering journalist with 10+ years across SaaS, AI, and live events, he has done everything from launching PostHog's startup program to shipping product features. We use PostHog at Boki and advocate for it openly - so when Joe speaks about what actually works in developer marketing, I pay attention.
2. Addison Schultz -Developer Relations Lead at GitBook | LinkedIn
Addison leads DevRel at GitBook, one of the most widely used documentation platforms in developer tooling. He previously held developer advocacy roles at Miro and Framer, and published the State of Docs 2026. He sits at the intersection of docs, AI, and developer adoption every single day - which makes his take on how developers actually discover and evaluate tools particularly sharp.
3. Tessa Kriesel - GTM at Mozilla and Founder at Built for Devs | LinkedIn
Tessa brings over a decade of DevRel leadership at companies like Snap and Twitter. She now leads GTM at Mozilla while also running Built for Devs, a developer adoption intelligence platform for dev tool founders. If you spend any time in the marketing to dev community you already know Tessa. She is one of the most active and generous voices in the space, consistently showing up to answer questions, share resources, and help people navigate careers in developer marketing.
4. Brian Neville-O'Neill - Developer GTM | LinkedIn
Brian has spent his career at the intersection of content and go-to-market for developer tools and AI infrastructure. He was Director of Content at LogRocket and has since held GTM leadership roles across multiple developer-focused companies. He now consults as fractional Head of GTM at Invarium AI. His core thesis - that most developer marketing problems are actually product problems, is one of the more useful reframes I have come across in this space.
5. William Imoh - Founder and CEO at Hackmamba | LinkedIn
William is one of the few people I know who was a developer first and a marketer second. He started his career as a software engineer and developer advocate, crossed over into building Hackmamba, and that crossing leaves a mark on how you think about this space. His takes on developer behavior are some of the bluntest in this piece, and blunt tends to be right.
6. Alexander Rozhkov - Head of Marketing at Verda | LinkedIn
Alexander came into developer marketing from B2B SaaS and has spent the years since unpacking what translates and what does not. At Verda, a developer infrastructure company that recently closed a €100M funding round, he leads full-stack marketing across AI and developer tooling. His perspective is especially useful for anyone making the same transition he did, from traditional SaaS GTM into the developer audience.
7. Shane O'Connor - Head of Growth at APIwiz | LinkedIn
Shane has spent five years building GTM engines for API and developer tools. He was part of the founding GTM team at Scalar, a developer tool that grew largely through community virality and developer word of mouth. Before Scalar he was at Tyk, working new business across multiple personas inside large technical organizations. He understands developer psychology well and shares some sharp takes on it below. Worth paying attention to.
8. Henry Bassey - Technical Marketer and Content Strategist at Hackmamba | LinkedIn
Henry leads content strategy and marketing operations at Hackmamba. He has worked with developer-focused companies including Novu, Flutterwave, and Sourcegraph. He has written and edited hundreds of technical pieces across DevOps, AI/ML, platform engineering, and developer experience, and his work has been featured on platforms like The New Stack. He understands this audience from the inside.
Marketing to developers: 17 lessons from the people who do it best.
1. Developers are not allergic to marketing. They are allergic to bad marketing.
It's only bad marketing that doesn't work for developers. The common wisdom is that developers are allergic to marketing. The truth is they're allergic to bad marketing. What is bad marketing? Boring content, constant calls to 'talk to sales,' and overhyped promises that don't actually deliver.
My read: Plausible is the example I keep coming back to here. They bootstrapped the whole thing, took no outside money, never ran a paid ad, and still crossed a million in ARR as a profitable company. The engine was useful writing and showing up on Hacker News.
One of their post on ‘how to pay your rent with an open source’ project pulled 35,000 visitors in a single day. Pricing sits right on the page, the roadmap is public, even their own traffic stats are public, and there is no demo to book anywhere. Developers paid them because every signal said this company had nothing to hide. That is the version of marketing this audience actually rewards.
2. Herd mentality is a real distribution lever.
Devs are short-tempered so winning sometimes means triggering them. There's insane herd mentality, betting to critical mass is a goal.
My read: shadcn/ui is the herd in motion. It was just a set of copy-paste components someone pushed to GitHub in 2023. By early 2026 it was north of 100,000 stars, and the JavaScript Rising Stars report named it the most popular project of 2024 by new stars, ahead of every framework and runtime in the ecosystem. Part of how it got there was friction. The creator kept insisting it is not a component library, which set off endless arguments, and every argument put it in front of more developers. Once enough people were using it, reaching for it stopped being a decision and became the default. That is critical mass doing the distribution for you.
3. Demonstrated competence beats brand authority every time.
Demonstrated competence beats brand authority. Developers are constantly evaluating whether you know what you're talking about. The companies that win tend to teach, build, document, contribute to open source, and participate meaningfully in communities. They show their work.
My read: Tailscale is the cleanest version of this I know. They publish deep engineering posts that teach the hard problem behind their product, the most famous being a long walkthrough of how NAT traversal actually works, written so generically it applies to WebRTC, VoIP, and games and even hands you the recipe to build your own. Developers read that and conclude these people understand the problem at a level no marketing claim could fake, and that conclusion is what sells the product. Years later, engineers who do not even use Tailscale still cite it.
4. Fix the first 10 minutes before you touch the homepage.
Onboarding friction kills more deals than bad messaging. Most marketers obsess over the landing page. But a developer who signs up and can't get to a working result quickly is gone, and no nurture sequence brings them back. Time-to-value is the metric that matters. Fix the first 10 minutes before you touch the homepage.
My read: Clerk is built so the first working result shows up in minutes. You install the SDK, set one key, wrap your app in their provider, and drop in a SignIn component, and a production-ready login flow with social auth and MFA is running on your own app. Building that by hand means writing password storage, email verification, account recovery, and session handling, which costs weeks and usually ships with security holes. Clerk compresses all of it into the first ten minutes, the exact window Tessa says decides whether a developer stays.
5. A big brand logo means nothing to a developer.
Focus on specific quotes tied directly to your ICP. Developers don't care that a big brand uses your tool. They care whether someone like them solved the same problem they have. One honest, specific sentence from a real user beats a page of logos
My read: A logo wall tells a developer that some procurement team signed a contract, which says nothing about whether the tool fixed a problem like theirs. If they do not recognize the companies, the strip reads as noise. What converts is one quote from someone on their stack that names the problem they were stuck on and the result after switching. You only get those by asking your best users what they were fighting before the tool and what changed after, then publishing the answer in their words. The specific sentence is the asset and the logo wall is filler. Raycast does this well and is worth taking inspiration from.
6. You have 10 seconds. Use them well.
10 seconds or you've lost them. If they do hit your website, they need to instantly understand: what you do, that you understand their pain better than they can articulate it, and how they get started right now. No friction, no forms, no 'book a demo.'
My read: Bun passes Shane's test before you finish reading the first line. The homepage states it in one sentence, a fast all-in-one JavaScript runtime that bundles, installs, and runs your code, which tells you what it is and quietly names the pain every JS developer feels from wiring up Node plus npm plus a bundler plus a test runner. Right under it sits a single curl command you can paste to be running in seconds, with no account, no form, and nobody asking you to book a demo. You understood the product and started using it inside the ten seconds Shane is talking about.
7. The fundamentals of marketing still apply.
Most of the marketers in my circles come into developer marketing from B2B SaaS. And most have picked my brain about the same thing - trying to apply the B2B SaaS playbook when marketing to developers. Virtually none of the typical B2B SaaS personas will interact with your product exclusively through API while being completely blind to all your comms efforts. That's a niche challenge that catches many newcomers to developer marketing by surprise. On the other hand, the fundamentals still apply. It's all about finding the product-market fit, the value prop for each audience, and building a relationship with them. If there's value in your product, the message you crafted resonates, and you delivered where it's seen, you've got a lot sorted.
My read: This is why people say product and marketing are the same thing in devtools. The product sells itself every time someone runs it, so your highest-leverage marketing move might be rewriting one confusing error message into a clear one. That fix reaches a developer in the exact moment they are stuck, which no campaign can do. The real work is making the surfaces they already touch worth talking about.
8. A coordinated influencer launch can become the problem.
A poorly executed influencer launch does more damage than no launch at all. The developer community is a distributed verification system. When a coordinated influencer network goes live, multiple people simultaneously pull different threads. Some check the technical claims. Others verify credentials, engagement ratios, and disclosure compliance. The influencer network became identifiable as a network, and that made the social proof actively negative. The distribution method itself became a signal about the company."
My read: Reflection 70B is the cleanest example of Henry's point I can think of.
In September 2024 it launched as the top open-source model in the world, with benchmarks to prove it, and a wave of influencers and tech outlets amplified it within hours. That reach is what sank it. All the attention pointed thousands of developers at the claims at once, and within days r/LocalLLaMA had traced the official API to Claude, independent testers could not reproduce the headline benchmarks, and the team ended up publicly apologizing for the damage to the open-source community. That is the mechanism Henry names: the more reach a thin launch gets, the more skeptics it points straight at the gaps, and the faster the whole thing comes apart where everyone can see it.
9. Marketing is still for people. Even in the age of AI.
There is no difference between B2B and B2C marketing. I've done both and, while there are differences in processes and priorities, the reality is that all marketing is for people. Even in the AI age, marketing is still for people - because creating a brand preference is the easiest way to get a user to keep returning to your product.
My read: Tailwind is the cleanest proof of this I can think of. In the State of CSS survey it holds a retention rate up in the high seventies, which means roughly three out of four developers who try it keep using it. That is brand preference showing up as a hard number. Adam Wathan built the audience first by teaching, the screencasts, the writing, the Refactoring UI book, so by the time people reached for Tailwind they already trusted the person behind it. Developers kept coming back because the brand actually meant something to them, and that is about as human as marketing gets.
10. You need two types of campaigns. Most teams only build one.
You need 2 types of campaigns, the short bursts and the long-lived. One for small launches and another to sustain engagement.
My read: Vercel runs this split cleanly. The short bursts are their two flagship conferences, Vercel Ship and Next.js Conf, where they stack the big announcements and let the whole community show up at once. Between those spikes, the long-lived engine never stops, because the changelog ships constantly, the blog publishes all year, and the templates gallery gives people a reason to come back every week. The conferences pull people in, and the steady drip is what keeps them there long after the keynote ends. Plenty of teams build the first muscle and never build the second, then wonder why the launch glow is gone by the next quarter.
11. CLI-first onboarding is a growth advantage now.
Onboarding flows and emails are changing how people work with your product. Developers use agents to evaluate and set up tools. If your onboarding only works by clicking through a UI, you're already losing. The teams getting adopted fastest have great CLIs, clean API docs, and setup flows an agent can actually run.
My read: Fly.io built its whole onboarding around this. You install flyctl, run fly launch in your project folder, and the CLI scans your code, detects the framework, writes a sensible config, builds the image, and ships it to a live URL. The whole path from source to running app takes about two commands and never leaves the terminal. A coding agent can run that start to finish on its own, which is exactly the setup flow Addison is pointing at.
12. Partnerships compound. Start earlier than feels necessary.
Partnerships are key to ecosystem growth, hard to build but compounds a lot. Start building them from day 1. Novelty is everything to people that believe they can build anything.
My read: Datadog is the compounding William is describing, just stretched over more than a decade. They started narrow, one agent collecting host metrics, and added an integration every time their customers adopted something new, moving from cloud providers to Kubernetes to serverless to the whole SaaS sprawl. By late 2025 they crossed 1,000 integrations, and roughly a third of those are built by outside technology partners. That is the compounding part. Every integration makes the platform stickier for the customers already on it and pulls in the partner's users at the same time. None of this happened in a quarter. They have been signing partners since the early days, and the moat is the sum of hundreds of small integration deals nobody noticed one at a time.
The highest-converting developer content is the content most marketers are afraid to publish. Honest comparisons that admit where a competitor is genuinely better. Migration guides that don't pretend the switch is painless. Developers will discover your weaknesses anyway, so be the one who tells them. That honesty is how you earn trust with a technical audience - and trust is the entire game.
My read: Meilisearch put its competitor comparison inside the docs and added a line inviting anyone to open a pull request if something looks wrong. A marketing page you can file a bug against cannot quietly cheat. The page backs it up too, since it openly credits Algolia and says Meilisearch studied Algolia's algorithms and blog posts to build its own engine. It even points you to Elasticsearch if you are working with huge volumes of log data. By the time they explain where Meilisearch wins, on price and simplicity for end-user search, you believe it, because everything before it was checkable and fair.
14. Pricing must be dead simple.
Pricing must be dead simple. No enterprise-speak, no 'contact us,' no 47-column comparison tables. Just tell them what it costs. Developers respect transparency and punish complexity.
My read: DigitalOcean built a business on doing exactly this. Their pricing page lists the actual numbers, Droplets from $4 a month, managed Postgres from $15, a load balancer at $12, with monthly caps so the bill cannot quietly balloon. You can size a whole production stack and know what it costs before you ever create an account or talk to anyone. That transparency is a big part of why developers reach for DigitalOcean when they just want to ship without decoding a pricing calculator. The price is the pitch.
15. "Developers" is not one audience.
There are devs and there are indie hackers who are developers - don't confuse both.
My read: This is the line I wish more teams sat with. When we say developer we are usually talking about two different people. One is the indie hacker building their own thing, spending their own money, deciding in the time it takes to read a homepage whether this is worth a weekend. The other is the developer inside a team, who has to fit your tool into an existing stack, get it past review, and convince the people next to them it was a good call. It is the same job title hiding two completely different buying behaviors. One wants to know how fast they can ship something real on their own. The other wants to know it will hold up in production and that they can defend the choice six months later. Aim a single campaign at developer and the copy lands softly on both. Knowing which one you are writing for is most of the work.
16. If agents can't make sense of your docs, you're losing top-of-funnel you don't even know about.
Optimize for agents, not just humans. Developers don't just Google things anymore - they ask Claude, Cursor, ChatGPT. If your messaging is full of vague marketing claims, agents will discount or ignore it. The teams winning developer mindshare right now are the ones whose docs, metadata, and web presence are written to be useful to AI, not just persuasive to humans
My read: This shift already happened. Developers now start inside their coding assistant, so the first thing reading your documentation is often a machine deciding whether to recommend you and how to wire you up. When someone asks Cursor or Claude Code to set up your tool, the agent goes looking for a clean, structured version of your docs, fetches it, and writes the integration straight from what it finds. If all it can find is marketing copy buried in heavy HTML, it gets the setup wrong or quietly reaches for the competitor whose docs it could actually parse. That is why the llms.txt standard caught on so fast with developer tools, a plain Markdown map that hands agents the right pages instead of making them scrape your whole site.
17. Developer social proof follows a specific hierarchy.
Numbers a developer can independently verify anchor credibility in ways general claims cannot. A live deployment counter or a star count in the navigation bar communicates trust in a format technical audiences understand and can check. Logo walls are less important compared to usage metrics, deploy counts, or star counts. Logos tell developers other companies paid for the product. Numbers tell them other developers are actually using it."
My read: Vite makes Henry's case better than any logo wall could. Its weekly download count sits on npmjs.com for anyone to pull up in two clicks, so the proof that developers actually use it is something you can confirm in seconds. That is the whole distinction. A logo on a page tells you a company once signed a contract. A download count, a deploy counter, or a star graph tells you developers reached for the thing recently, and it hands you the receipt to check. Numbers you can verify are the one kind of social proof a skeptical audience never has to take on trust.
Wrapping up:
Every DevGTM expert shared valuable lessons on marketing to devs, but if I had to summarize everything into one takeaway, it would be this: be honest. More than almost any other category, honest marketing wins in devtools.
Developers don't buy because your landing page says you're the fastest or the easiest. They buy because another developer mentioned your product in Slack, recommended it in a thread, or talked about it at a conference. Word of mouth is the real distribution channel.
That also means every claim you make gets repeated, questioned, and verified by people you don't control. If it's true, your reputation compounds. If it isn't, that compounds too. The goal is to be consistently verifiable in front of an audience that checks everything before they trust you.
This is the principle we build on at Hackmamba, the developer marketing agency, because when your audience verifies everything, honesty becomes the most practical strategy you have.
Henry summed it up with one question that stuck with me: What happens when the most skeptical developer in your audience decides to pull every thread in public?
Build your marketing for that person. If they believe you, everyone else probably will too.
