You build a developer community by choosing a narrow topic, starting with ten people you already know, running one recurring event they can rely on, and making the first contribution for a newcomer trivially small. Communities die from emptiness, not from lack of features, so the early job is activity, not tooling.
1. Narrow topic, clear reason
"A community for developers" is too broad to join. "Flutter developers in Lahore", "people building CLIs in Rust", "self-taught backend developers" are joinable. Write one sentence on why it exists and what someone gets from it that they cannot get elsewhere.
2. Ten people first
Before opening the doors, personally invite ten people you know who fit the topic. Ask each to post one thing in the first week: a project, a question, a link with a comment. Ten posts make a place look alive; an empty space makes even good newcomers leave.
3. One recurring event
Pick something you can sustain: a weekly "what are you working on" thread, a monthly live room where people demo, a fortnightly office hours. Same time, same format, every time. Reliability is what turns visitors into members. On DEVAE a community can host rooms and threads in one place, which keeps the event and the conversation together.
4. Rules and moderation from day one
Write short rules (what is welcome, what is not, how to report) and enforce them from the first week. Remove spam within hours. The tone of the first hundred posts sets the tone for the next ten thousand; if the early posts are helpful and specific, newcomers copy that.
5. A two-minute first action
Newcomers who do something in their first session stay. Make that something small and obvious: introduce yourself with your stack, answer the weekly thread, react to a project. Pin it. Thank people who do it.
Growth, honestly
Growth comes from members inviting people, from public artifacts (recaps, posts, room recordings) that show up in search, and from being listed where people look for communities. It does not come from ads. Expect fifty active people after six months of consistent effort; that is a healthy community, not a small one.
What to measure
Weekly active posters, replies per post, and how many newcomers post within seven days. Member count is vanity; a thousand silent members are worse than fifty who talk.
When to add structure
Add sub-groups, roles and tooling only when the existing space is too busy to follow. Structure added early is empty rooms with labels.
A worked example
Two developers in Islamabad want a community for Flutter developers in Pakistan. They write the reason ("Flutter devs here have no place to share work, ask questions in the open and find teammates") and invite ten people they have worked with, asking each to post a project in the first week. They pick one ritual: a monthly Sunday-evening live room where three members demo something. They write four rules and remove the first spam post within an hour. Newcomers are asked to post their stack and current project as a first action. After six months there are around sixty regulars, a handful of hackathon teams that formed there, and a recap post after each demo night that new members find through search.
Questions people ask
**Should I start on my own platform or an existing one?** Start where the ten people already are, then move if the tooling limits you. Communities are people first; the platform can change.
**How do I keep it going when I lose energy?** Share the ritual. Rotate who hosts the monthly room, add a second moderator by month three, and let members run threads. A community with one point of failure has one.
**When is it too small to bother?** Never, as long as people reply to each other. Twelve active members who help one another is a community; growth is optional.
