Community Building

Why community compounds

A developer community is the only DevRel asset that answers questions while you sleep. Every solved thread becomes searchable capital, every active member lowers the load on the next one, and the resulting network effects are the core of why DevRel matters commercially.

That is the payoff. The cost is that community is slow to start, easy to fake with vanity numbers, and impossible to outsource.

Do you actually need one yet?

Be honest about this gate before creating anything.

A community space earns its existence when three things are true:

1. Developers are already using the product in production, or seriously trying to.
2. They ask questions with answers worth preserving.
3. Someone on your side will show up every day for the first months.

If those are not true yet, a community space becomes an empty room with your logo on it, and an empty room actively signals that nobody uses the product.

Until the gate is met, participate in external communities instead: it reaches developers where they already are, at a fraction of the cost.

Choosing the home

Every option trades reach against ownership.

• GitHub Discussions: lives next to the code, indexed by search engines, zero extra accounts for developers. Weak for real-time chat and casual presence.
• Discord: excellent for real-time energy and voice events, familiar to most developers. Content is unsearchable from the outside and effectively disappears; treat it as ephemeral by design.
• Slack: comfortable for B2B audiences that live in Slack at work. Message history limits and workspace sprawl make it a poor archive.
• A forum such as Discourse: the best long-term archive, fully owned, search-indexed. Higher setup and moderation cost, and it feels slower socially.

A practical pattern: one real-time space for presence plus one indexable space for durable answers, with the discipline to move solved chat threads into the indexable one. The worst pattern is four half-alive spaces.

The cold start: your first fifty members

Communities do not start with scale, they start with hospitality. Do things that do not scale:

1. Invite people personally: your first users, beta testers, the developers who filed thoughtful issues. A personal note beats any announcement.
2. Be present daily: founders and DevRel answering within the hour sets the tone for everything after.
3. Seed real content: post the questions you get by email, with answers, so the room never looks empty.
4. Create one ritual: a weekly office hour, a Friday showcase thread, a monthly call. Rituals give people a reason to come back.
5. Welcome individually: greet every new member by name for as long as that is physically possible.

Expect the 90-9-1 shape: roughly ninety percent of members read silently, nine percent respond, one percent create. Design for the readers too; they are adopting your product even when they never post.

Growing past the founder era

Once strangers answer strangers, shift from hosting to building programs:

• Office hours and AMAs: scheduled access to your team, cheap to run, reliably productive.
• Showcase channels: members demoing what they built, which doubles as a content and case-study pipeline.
• Champions or ambassador programs: give your most invested members early access, a direct line to the team, and a stage. Design incentives around recognition and access rather than payment; paying for advocacy converts your most credible voices into contractors.
• Community-sourced content: guest posts and talks by members, reviewed for accuracy by your team.

Set the guardrails early:

• A short, enforced code of conduct from day one. Publishing it after the first incident is too late.
• Moderation coverage: name who acts, and how fast, when something crosses a line.
• An explicit escalation path from community questions into your issue tracker, so recurring pain becomes product feedback instead of folklore.

Showing up in communities you do not own

Most of your audience will never join your space. They are on Stack Overflow, Reddit, Hacker News, and in other products' Discords, and how you behave there shapes your reputation more than anything you do at home.

What works:

• Answer questions about your problem space, not just your product, and be genuinely useful.
• Disclose who you are every time; a bio line and a plain "I work on X" is enough.
• Follow each community's self-promotion rules to the letter.
• Bring value first: share the fix, then link the deeper guide if it genuinely helps.

What burns trust permanently:

• Drive-by promotion in threads you never participated in before.
• Undisclosed employees "recommending" the product.
• Copy-pasted marketing responses to nuanced technical questions.

Measuring community health honestly

Member count is the weakest possible signal: it only ever goes up, and it says nothing about life inside. Track behavior instead:

• Active participants per week or month: people who posted, replied, or reacted.
• Time to first response for new questions, and who responded.
• Member-answered ratio: the share of questions resolved by non-employees. This is the single best indicator that a community, not a support desk, exists.
• Returning participants: members active this month who were also active last month.
• Qualitative signals: unprompted show-and-tell, members defending nuance in public threads, inside jokes.

Set targets for these the same way you set any goal, with explicit measurement definitions, as laid out in the OKR planning guide.

Related

• DevRel activities for where community fits among the other clusters
• Content creation for turning community questions into durable content
• Understanding developer personas for knowing who you are hosting in the first place

---

Sources & References:

• The 90-9-1 Rule for Participation Inequality in Social Media and Online Communities by Jakob Nielsen | Nielsen Norman Group, 2006
• The Art of Community by Jono Bacon | O'Reilly, 2nd edition 2012
• The Business of Belonging: How to Make Community Your Competitive Advantage by David Spinks | Wiley, 2021