Running a small community realistically takes three to five hours a week; a mid-sized one takes eight to fifteen; and past that it stops being something you fit around other work. Those numbers surprise people mainly because most of the hours go somewhere they did not expect.
Almost nobody budgets for this honestly before starting, which is why so many communities go quiet in month four.
The hours you plan for are not the hours it takes
Ask an owner what running a community involves and you get an answer about posting: writing the weekly prompt, sharing an update, replying to comments. That work is real, and it is maybe a third of the total.
The rest is invisible on a calendar. Deciding whether a borderline post crosses a line. Answering the same question in five separate direct messages because nobody wrote it down. Noticing that a regular has gone quiet and deciding whether to reach out. Re-reading a message three times before sending it because the member is upset. Sitting with a judgment call you are not sure about.
That work is not slower than posting — it is heavier. An hour of writing leaves you fine; an hour of adjudicating a conflict does not. Owners who budget only for the visible half consistently end up feeling that the community takes far more out of them than the clock suggests, and conclude something is wrong with them rather than with the estimate.
Realistic weekly hours by stage
These are the ranges that hold up in practice, assuming you are not paying anyone yet.
| Stage | Hours a week | Where they actually go |
|---|---|---|
| Pre-launch | 10 to 20, briefly | Structure, guidelines, seeding content, inviting people one by one |
| Under 100 members | 3 to 5 | Mostly you posting and personally welcoming people |
| 100 to 1,000 | 8 to 15 | Moderation decisions, direct messages, events, the first real conflicts |
| Over 1,000 | 20 or more without help | Escalations, team coordination, and everything above at volume |
Two things about this table matter more than the numbers. The pre-launch spike is short and worth it — the work you do before anyone arrives is the cheapest work you will ever do, because there is nobody to disappoint yet. And the jump from the second row to the third is where most communities break, because it arrives as a gradual slope and owners absorb it by working more until they cannot.
The tasks that scale and the ones that do not
The single most useful thing to understand about community time is which work grows with member count and which does not.
Roughly flat, regardless of size: writing the weekly prompt, running one event, publishing an update, maintaining the structure. A community of 2,000 needs the same one prompt as a community of 80.
Grows with size: moderation decisions, direct messages, welcoming, conflict, and answering repeat questions.
This is the whole strategy in one line: the fixed work is where your time creates value, and the growing work is what you must systematically get out of. Owners who burn out are almost always the ones who let the growing half absorb the hours they used to spend on the fixed half — the prompt stops, the event slips, and the community gets quieter while its owner works harder than ever.
What actually reduces the hours
Four things move the number meaningfully. Most other advice does not.
Write decisions down once. The repeat question answered in five direct messages is the most reliable time sink there is, and a pinned post or a searchable public answer ends it permanently. This is the same mechanism that makes a public question-and-answer space deflect support load — see the customer academy guide.
Automate the noise, never the judgment. Spam filters, welcome messages, and event reminders are pure savings. Deciding who stays and who goes is not automatable and should not be — more in automating your community.
Make rituals boring. A prompt that follows a template takes ten minutes; one you reinvent weekly takes an hour and eventually gets skipped. The predictability is what makes it survivable, and it is also what makes it work — see the engagement strategy.
Bring in help before you need it. Recruiting volunteer moderators while you still have the patience to train them is the difference between delegating and dumping. The signal is the first time you notice something a day late.
If you only have two hours a week
Then build a two-hour community, deliberately, and say so out loud.
A small community with one reliable ritual and forty engaged people is a genuinely good outcome. A large community with an absent owner is not — and the second one is what you get by aiming big with a small budget of hours.
The failure is not having limited time. It is promising the experience of a well-run community while having the time for a lightly-run one. Members forgive small; they do not forgive neglected.
The signals you are over your limit
Three of these show up before burnout does, and all three are easier to act on early.
You dread opening it. Not bored — actively avoiding. This is the earliest and most reliable signal, and it usually appears weeks before anything visible changes.
The fixed work is slipping. The prompt is late, the event moved, the update did not go out. That is not laziness; it is the growing work having eaten the fixed work.
You are answering everything. If no thread resolves without you, you have built something that depends on your presence, and it will consume whatever hours you give it. That is also, incidentally, why it goes quiet when you step back.
When it becomes someone's job
At some point the honest answer is that this is no longer a side activity.
The threshold is not member count. It is when the community generates enough value — revenue, retention, support deflection — that the hours are worth paying for, and when the work has become predictable enough to hand over. Both usually arrive somewhere in that 100-to-1,000 band.
Hiring does not remove your hours entirely, and owners are often surprised by that. It changes what they are spent on: less moderation triage, more direction. What the role actually contains is in what a community manager does.
The bottom line
Budget three to five hours a week for a small community, eight to fifteen once it is genuinely active, and assume the invisible half — decisions, messages, judgment — will be the heavier half.
Then protect the fixed work, systematically offload the growing work, and size the community to the hours you actually have rather than the hours you wish you had. Communities do not usually fail because the owner ran out of ideas. They fail because the owner ran out of Tuesdays.