I'm a developer. I wasn't always one, though.
For the first ten years of running CrazyEngineers, I couldn't write code. Every small feature meant chasing freelancers, and what came back often broke. In 2015 I got tired of it and taught myself PHP. Eight months later I shipped my first plugin. A few years after that, I built a complete community platform from scratch, on my own.
So I know developers from both sides: as the people I used to depend on, and as one of them. And here's what I've learned. Developers are the hardest tribe on the internet to please.
They have options everywhere. Stack Overflow, GitHub, Reddit, Discord servers, docs, and now AI tools that answer in seconds. They build the products and services the rest of the internet runs on, and they can smell marketing from a mile away. If your community doesn't offer something genuinely useful, they won't come back.
I've built a developer community at a B2B SaaS company where I led growth, and today I build Jatra, a community platform. So I have opinions on platforms, and I'll tell you when they matter. This guide is how I'd build a developer community today.
New to communities in general? Start with how to build an online community. This guide goes deeper into what's different for developers. If your developers are also your paying customers, read how to build a B2B SaaS customer community too. Maintaining an open source project? Read how to build an open source community.
Why developer communities are hard now
Two things make it harder than it used to be.
The first is competition. There are several communities for almost every language, framework and tool. A new one has to give developers a reason to show up that the others don't.
The second is AI. A lot of the quick questions developers used to post publicly now go to ChatGPT or Claude instead. One study found that posting on Stack Overflow dropped by about 25% within six months of ChatGPT's release, compared with similar sites, across every experience level.
But there's an upside too. AI answers the generic questions. It's weak on the specific, real-world ones: the edge case in your SDK, the integration that breaks in production, the trade-off nobody wrote down. That's exactly where a good developer community wins.
And developers really do want to talk about AI itself. AI tools, vibe coding, how to work with assistants without shipping garbage. These are some of the topics developers care about most right now, and a community can bring them together around them.
Know the developers you're building for
Before anything else, get clear on who these developers are.
What stack do they use? What are they trying to build? Where do they get stuck? What do they fear: a broken deploy, a security hole, looking stupid in front of their team? What would make their week easier?
Write it down. Half a page is enough.
Tip: Read your GitHub issues, support tickets and the questions people ask about your product on Stack Overflow and Reddit. Developers have already told you exactly where they struggle.
Narrow it down until you can win
This is the most important decision you'll make.
At the B2B SaaS company where I led growth, we didn't build a community for "developers". We picked a very small niche: React developers looking to add video and images to their apps. That was super relevant to our product, and it helped us find the exact problems those developers were facing.
That's the right approach. When you solve specific problems that other forums and communities aren't solving, you basically eliminate the competition. Nobody else is going that deep on that one thing.
So go deep. Answer the long-tail questions, the very personal, very specific ones developers actually face. "How do I lazy-load video in a React list without killing performance?" is a better first thread than "Best video libraries in 2027".
Once you own that niche, widen it naturally.
Pick a platform built for answers
Most developer communities start on Discord, or on GitHub Discussions next to the repo. I understand why: developers are already there.
If your community is growing and you're happy with it, stay. There's no reason to move a community that's working.
But if you want the community to grow on its own, to bring new users to your product and keep the ones you have, look at a proper community platform. Here's why.
Chat buries good answers. A developer posts a brilliant fix. Ten or fifteen messages later, it's gone. Nobody outside the server will ever find it, and even members have to search for exactly the right keywords to dig it up. So the same questions come back every week, and your best people get tired of answering them.
Discord has announced that from November 16, 2026, large public Discoverable Servers get a web page, and some new messages will gradually become searchable from mid-December. It's a step, but older messages and private channels stay hidden, and those pages live on Discord's domain, not yours.
A proper platform lets you go hybrid. Keep the Q&A and discussions public, where Google and AI tools can find them. Keep anything sensitive private. And you get more than threads: articles, guides, quizzes, job posts, events and feedback, all in one place. Chat platforms make you bolt those on with outside tools.
If you're weighing up a move, I've compared the options in Discord vs Jatra and when to move your community off Slack, Discord or WhatsApp.
Seed it with deep answers
Before you invite anyone, fill the community with answers worth finding.
Take the questions from your issues, tickets and the forums developers already use, and answer them properly. Include the code. Explain the why, not just the fix. Link to your docs where it helps.
I usually recommend about 50 pieces of content in the first 10 to 15 days. Depth matters far more than volume. One thread that fully solves a painful problem beats ten shallow ones.
Mix it up, too. Developers aren't only looking for code snippets. Hold a good mix of technical and non-technical content: how-tos and debugging threads, but also career questions, tool comparisons, opinions on where the stack is heading, and yes, AI and vibe coding.
The full method is in how to seed a community.
Invite developers in batches
Don't announce it to everyone on day one. Invite in batches.
Start with developers you can actually talk to: active users of your product, people who've filed thoughtful issues, contributors, friends in the niche. Give them early access, then watch what they do. Which threads do they read? What do they ask next? Do they come back?
Their behaviour is the feedback. Fix the gaps, write the missing answers, then invite the next batch. You'll do this for the first 20, 30, 50 members before developers start joining on their own.
Recognise the developers who help
Most developers want recognition they never get anywhere else. Give it to them.
It's easy to spot the good ones. They share code snippets. They help each other without expecting anything in return. They answer the question you didn't have time for.
Recognise them in public. At CrazyEngineers, we ran "Know Your CEan", member interviews with fun, personal questions, published right inside the community. People loved being in the limelight. A developer spotlight works the same way: a short interview about what they're building, how they got into it, and what they'd tell a beginner.
Simple recognition goes a long way. A thank-you from the team, a badge for accepted answers, a mention in your changelog when their feedback shipped. None of it costs much, and all of it makes people want to give back.
Watch, refine, repeat
After every batch, look at what worked. Which answers got used? Which questions came up that you hadn't covered? Who came back a second time?
Write what's missing. Then invite the next batch. Keep this loop going for the first few weeks, and you'll have a solid foundation.
Let Google and AI find your answers
Once your public answers get indexed, the community starts growing on its own. A developer searches for their exact error, finds your thread, sees that it's solved, and signs up to ask the next question.
This is where the niche pays off again. Long-tail developer questions are exactly what people type into Google and ask AI tools. Answer them well, in public, with accepted answers marked clearly, and you become the source.
It keeps compounding, too. Discussions we wrote on CrazyEngineers back in 2010 still bring in hundreds of visitors every month.
A few things help a lot. Give every question its own page with a clear title. Mark the accepted answer. Keep URLs permanent. And link to your best threads from your docs, your README and your support replies. On Jatra, Q&A threads carry structured data that tells search engines which answer was accepted, so they understand the page faster.
Moving from Discord or GitHub Discussions
If your developer community is well established and thriving, don't move it. Seriously.
But if it isn't growing, or it isn't living up to its potential, it's time to consider a new platform. Move, open it up to search, and let it grow from there.
Be realistic about the first weeks. In my experience, on average about 10% of members move over at first. It's not set in stone, but don't expect everyone on day one. Members like the new platform once they're there, because it gives them more ways to post and interact. Then new developers start finding you through search, and old members come back once they see activity.
That's what happened with DMTWorld, a community that moved from Discord to Jatra. About 10% of members came across in the first few months, and once members were contributing, the owners emailed the old member base and many more became active. More on doing this without losing people in the community migration guide.
Keep it human
One warning. Don't let AI do the talking.
I've watched AI auto-replies in a very popular developer community. Because the AI answered first, members stopped replying. A lot of the human connection was lost.
Use AI to help your team: drafting, summarising, catching spam. But the conversations should be human. Developers come to a community to talk to other developers. If they wanted an AI answer, they'd have asked one.
Frequently asked questions
Should a developer community be on Discord or a forum?
Use chat for real-time conversation if you like, but keep your knowledge somewhere searchable and permanent. A hybrid community with public Q&A and discussions grows on its own; a chat server depends on you inviting every new member.
How do you get developers to contribute?
Answer their specific problems better than anywhere else, and recognise the people who help. Developer spotlights, badges for accepted answers and a public thank-you go a long way.
Is a developer community still worth it with AI tools around?
Yes, if it's specific. AI handles generic questions well. A community wins on real-world edge cases, integration problems and opinions from people who've shipped the same thing.
How big should a developer community be before it works?
You don't need a big one. Start with a handful of developers you can talk to and about 50 deep answers. Grow in batches from there.
Who should run a developer community?
Usually a developer relations or developer advocate role, with engineers tagged in to answer the hard questions. More on the options in who should run your community.
Where I'd start
If I were building a developer community tomorrow:
- Pick one narrow group of developers and one problem they keep hitting.
- Choose a platform where every answer gets its own permanent, public page.
- Write about 50 deep answers, with code, before inviting anyone.
- Invite developers you can talk to, in small batches.
- Spotlight the ones who help.
- Let Google and AI bring the rest.
That's it. Developers are hard to please, but once you're the place that actually solves their problem, they stay.
If you'd like help building yours, see how Jatra works for developer communities, or book a call and tell us what you're building.
