Online Community Building: What to Do Before You Have Members

A workspace gets created in March and forty people accept the invite. By June it holds eleven messages, and four of them are yours. An empty room is a daily obligation, and no launch plan prepares you for it. A launch is one afternoon. This is a habit you keep while it is still unrewarding, and the first ninety days decide whether anyone is there when it starts to pay.

This page is about the work, not the decision: who you let in and what you promise them belongs to whoever sets strategy, and I am not making it there. What I can give you is the first ninety days of online community building: who to invite first, what the first thread says, what the hours cost, and what to close in month three.

None of it is difficult. Almost all of it is unglamorous, and the unglamorous part is the whole job.

What Counts as a Community Here

Three different things get called a community, and each one has a different first move. Get the kind wrong and every later decision inherits the mistake. Building an online community means knowing which of the three you are actually starting.

A support forum exists so people can get unstuck. Members arrive with a problem, get an answer, and leave. Your first move: find the five customers who already answer other customers in your inbox, and give them a room.

A customer group exists so people in the same seat can compare notes. Fix the cohort before you open the room: the same stage, the same problem. A room of beginners and veterans has nothing to say to itself.

A practice network exists so people can get better at a craft. Members come for a standard, so publish the standard: the way you do the thing, written down, so there is something to argue with.

You cannot run all three at once. Pick one.

The First Ten Members

Ten is enough to see whether the room has a reason to exist, and small enough to recruit by hand.

Jakob Nielsen published the 90-9-1 rule in 2006: in most online communities, 90 percent of users never contribute, 9 percent contribute occasionally, and 1 percent account for almost all the activity. That is a 2006 heuristic, not a measurement of your room. If participation is structurally unequal, then ten hand-picked people are not a miniature community. They are the 1 percent a later audience forms around. Recruiting them well is the whole job of week one.

Why You Recruit By Hand, and What "In Public" Means When the Room Is Empty

A list blast to four hundred people produces a room that looks alive for a week and is dead by the second. Hand recruiting is slower and it is the only version that works. Treat the first ten as co-authors rather than an audience.

"In public" does not mean a public post. When the room is empty, public means the places your future members already talk: your support inbox, replies to your newsletter, a call already booked. The invitation happens where they are, not where you wish they were.

Pick by problem, not seniority. The most useful filter is one step of your customer journey map: people stuck at the same step. They have the same question this month, which is what a first conversation needs.

The Invitation That Works Is a Question

An announcement asks for attendance. A question asks for an opinion, and an opinion is cheaper to give than attendance. Here is the invitation, in full:

Hi Dana, >You asked me in February why your onboarding emails stop working after week two, and I did not have a good answer. >I am putting eight people who asked me something similar in one room to compare notes. The first thread is a single question: what did you change in week two that you would not change again? >Would you answer that one? Nothing beyond it, and I will not add you to anything else. >Martin

Four moves are doing the work in those five lines: naming the exact question she asked, saying who else is in the room, asking for one answer instead of a commitment, and giving her a clean way to say no.

When she says yes, send the link, name the day the thread goes up, and leave it there. When she says no, ask which question she would have answered instead. That reply is usually a better thread than the one you wrote.

Who Not to Invite First

The loudest person in an adjacent space is not the person with the recurring problem. How much someone talks and whether they fit are different variables, and that is my reasoning, not a study finding.

Anderson and Kilduff (2009) found that people high in trait dominance were rated as more competent by their own group, by outside observers and by research staff, even after controlling for their actual ability. The study ran 68 students in 17 groups and 100 students in 25 groups, four strangers per group. It is work from 2009 about small face-to-face groups of strangers, so read it as small-group psychology, not community research. Still, in a ten-person room, dominance reads as competence and decides whose habits become the culture. Invite the person with the recurring problem.

The First Conversation

Skip the welcome post. A seeded thread is one question, written by you, that a member can answer in two minutes without owning your product.

The topic rule: pick a decision your members face this month. A feature you want them to use is your agenda, and a product question gets one reply, yours. A decision question gets an argument.

Where do the topics come from? The questions your buyers already send you. If you have written a B2B content marketing strategy, the raw material is in the research behind it: the objections, the alternatives, the thing they tried first.

The post:

The week-two change you would keep >Week two is where most onboarding sequences either work or quietly stop working. I have three theories about why and no data. >So: what did you change in week two that you would not change again? Not the answer that sounds right in a meeting. The thing you actually kept after a month. >If you have never touched week two, say that too. "We left it alone and it works" is a useful answer. >I will go first: we moved the second email from day 3 to day 7 and replies went up, then went back down when we added a third. I still do not know which change did it.

That post works for three reasons: a real decision, one answer instead of a discussion, and permission to answer briefly.

Then the hard part. In week one, reply second. If you are always first, members learn that the room is your inbox. Let a question sit for a few hours and answer the person who answers first.

What a Moderator Costs Before There Is Anything to Moderate

Everything here is an estimate with its assumptions printed, because no measurement of your room exists yet. Three bands that match a first ninety days, and effort inside each is dominated by reading every post and writing one prompt or reply. Moderation in the usual sense, removing spam and handling conflict, is close to zero under a hundred members. The cost exists before there is anything to moderate.

That table is an estimate, not a benchmark. The first band assumes the seed threads were written once, before day one, and are not a weekly cost. If you are still writing seeds during the first weeks, add 30 to 45 minutes a day and band one moves to roughly 6 to 9 hours a week.

Published vendor bands land in a similar shape: 3.5 to 7 hours a week for 0 to 100 members, 7 to 14 for 100 to 500 (StickyHive, 2026), with a survey basis declared but not verifiable. Take the shape, not the numbers.

Now the number you will find. One platform vendor's guide, at bettermode.com/blog/how-to-build-a-community and updated 15 August 2026, gives a single figure for every stage: "a quarter to half of someone's time". On a 40-hour week that is 10 to 20 hours, attached to a room of ten people. It is the only page I found that treats the first ninety days as a job, and it stops short of what a reader can use: a fraction instead of hours, no invitation, no worked thread, no shutdown rule. One fraction for every stage, attached to a ten-person room, is the number most likely to make you quit in week one.

Then money, where published figures disagree by nearly 2x for the same title in the same month. Salary.com puts a community manager at $52 an hour in October 2026. ZipRecruiter puts the same role at $28.34. Do not average them, because the average describes no job that exists. The gap is the finding.

Take the founder's hour at $46 (Glassdoor, 2026) and a freelance moderator at $15 to $45 an hour (EverestX, 2026). Use the junior end, $15 to $25, and your gap is $21 to $31 an hour before coordination: $74 to $140 a week in band one, $126 to $248 in band two, $189 to $372 in band three. Now the other side: contracted moderators averaged $62.54 an hour in September 2026 (ZipRecruiter), $16.54 more than the founder's hour. At that rate hiring never pays.

So the answer is conditional. In band one the money case for a paid moderator is weak: the hours are few and the coordination cost is real and unpaid. In band three it depends on what the released hours go to. If the founder's freed time goes to work worth more than $15 to $25 an hour, hire. If it goes to more meetings, you have bought nothing.

The Month-Three Review

Book the review before you launch it. Week twelve, one hour, four numbers. The thresholds below are mine, not an industry standard; set yours once and write them down beside these.

Returning members. Count the people who posted in two separate weeks. Not the member total. A large list of people who never come back is a newsletter with worse deliverability. Under ten returning names in a room of forty, the room is a mailing list with a login.

Threads with more than one reply. A thread with one reply is you answering a question. Two or more means members are talking to each other, which is the only thing you are trying to produce.

Unanswered questions. Keep this as a running list, not a monthly count. A monthly count hides the question that has been sitting there since the ninth. FeverBee's practice is to escalate an unanswered question at 24 hours and again at 48.

Time to first reply. Use the median. One forgotten question drags a mean into nonsense, and you would be reporting the outlier instead of the room. FeverBee publishes response speed at roughly 48 to 72 hours as an industry average, and that is practitioner guidance rather than a study; the median is also how CHAOSS defines Time to First Response.

Four numbers for one program in its third month is an operating check, not a framework. If you need the marketing KPIs that a leadership team reviews, that is a different job with a different owner.

Then the decision. The channel to close is the one that fails at least two of the four numbers while consuming the most moderator hours.

The rule, as I would write it into the plan:

Close the channel that fails two of the four numbers and costs the most hours to keep alive. Give two to four weeks notice; a community closing from inactivity needs a short runway (Quiip, 2020). Tell members why it is closing and what stays open. Post where the conversation continues, pin it, and redirect the old link so nobody lands on a dead room. Close on a weekday morning, not a Friday.

The last step is the one that gets skipped: move the people. Two weeks after the close, check whether the same names appear in the surviving room. If they do, you closed a channel. If they do not, you closed a community and kept the software.

What You Should Not Build

Three things to skip.

A platform before a practice. Software makes an existing habit easier. It cannot create one.

A gamification layer before a habit. Nielsen's curve means badges mostly reach the people who already post. A badge aimed at a lurker changes nothing, and that is a derivation from the participation heuristic rather than a finding. Earn the habit first and the badge becomes a small reward for something people were doing anyway.

A content calendar for a room with no conversation. A calendar fills a space you have not earned yet. If your community is a channel rather than a destination, the plan you need is a platform-level one, closer to an Instagram content strategy than to a forum.

Where Community Programs Die

The truism is that communities fail after launch, not at setup. It is true, and by itself it is useless. Here is what it looks like in week three.

Nobody owns it. Everyone's side project. The tell: a thread sits unanswered for two days and nobody notices, including you.

Launch was the finish line. The announcement went out, the team celebrated, the calendar emptied.

The metric rewards registrations. Signups are easy to move and tell you nothing about returns, so the whole team optimizes the invite and the room stays empty. By week three the number is up and the thread list is not.

One person writes. Every thread opens with your name and closes with yours. Members read that as your newsletter with a comment box, and they are right.

None of these look like failure from the inside. They look like a slow month, and that is why the month-three review carries numbers instead of a feeling. Pick the ten people this week, send the invitation, and write one thread they can answer on Monday. Put the month-three date in the calendar before you send anything, because that review is the decision that actually ends the program.