Structuring an online community means deciding how many spaces to create, what each one is for, who can see it, and how they are grouped โ before members arrive rather than after the feed gets noisy. It is the highest-leverage hour you will spend on setup, and the easiest thing to get wrong in both directions.
This guide covers how many spaces to start with, how to choose between space types, the access decisions you cannot easily undo, and when to add, merge, or retire a space.
The two ways structure fails
Every badly structured community is one of two shapes, and they fail for opposite reasons.
Too many empty rooms. Someone sets up fourteen spaces on launch day because each one seemed like a reasonable topic. Members arrive, see fourteen mostly-empty containers, cannot tell where anything belongs, and post nothing. Emptiness is contagious: a space with two posts in it signals that nobody is here, and that signal spreads to the spaces that were working.
One noisy feed. The opposite failure. Everything goes in one place, so beginners' questions sit next to advanced debates, announcements get buried under chatter, and every member sees content that is irrelevant to them. People do not complain about this โ they just stop opening the app.
Good structure is the narrow path between them: few enough spaces that each one feels alive, distinct enough that members know instantly where to post.
Start with three to five spaces
Three to five. Not one, not fourteen. This is the single most useful rule in community setup, and almost nobody follows it on the first try.
The reason is arithmetic. A community needs a critical mass of activity per space to feel alive, and splitting a small amount of activity across many spaces guarantees that none of them reach it. Consolidate first, split later โ that is a much easier correction than trying to revive twelve dead rooms.
A starting set that works for most communities looks like this: one space for announcements and start-here material, one main discussion space, one space for questions or help, and one space for wins and introductions. That is it. If you are running a course or a paid tier, add one space for it.
Our guide to building a community from scratch treats this as step three for a reason โ it comes before you invite anyone.
Choose the right space type for the job
Not every space should behave the same way. A question-and-answer board and a real-time chat room need genuinely different interfaces, and forcing both into a generic feed makes each of them worse.
On MateFlow, each space is created with a type that determines how content behaves inside it:
| Space type | Use it for |
|---|---|
| Feed | General discussion โ the default, and the right answer most of the time |
| Q&A | Help and support, where answers matter more than chronology |
| Chat | Real-time conversation, casual and fast-moving |
| Course | Structured lessons with progress tracking |
| Article | Long-form writing you want read rather than scrolled past |
| Gallery | Visual work โ portfolios, screenshots, before-and-afters |
| Radio | Audio and podcast episodes |
Two practical notes. First, the type is a design decision, not a cosmetic one โ a Q&A space encourages a different behaviour from a Feed space, and picking the wrong one produces a space that technically works and quietly underperforms. Second, some limits do vary by plan โ Starter includes three courses, for example, while Feed and Q&A spaces are available on every plan โ so check your plan if your structure leans on one type in particular.
Start with Feed for almost everything. Reach for a specialised type when you have evidence that the interaction is genuinely different, not because the option exists.
Public, private, or secret โ decide before you create
This is the one decision in this guide that is genuinely hard to reverse, and it is worth reading twice.
A space is created as public (anyone can find and read it), private (visible but requiring membership to enter), or secret (invisible unless you are in it). Each serves a real purpose: public spaces do your SEO and let prospective members see value before joining; private spaces hold the paid or trusted layer; secret spaces are for leadership, moderators, or a founding-member group that should not advertise its existence.
Here is the part that catches people: on MateFlow a space's privacy setting is fixed at creation and cannot be changed afterwards. You can rename a space, edit its description, change its icon, and move it to a different category โ but not flip it from private to public. Decide privacy deliberately, because the fix is creating a new space and moving people, not toggling a setting.
The practical implication for structure: keep at least one genuinely public space. A fully private community is invisible to search engines and to anyone deciding whether to join, which quietly removes your best acquisition channel.
Group with categories, not sub-spaces
Once you pass roughly eight to ten spaces, a flat list stops being navigable. The instinct is to nest โ spaces inside spaces inside spaces. Resist it, and not only because MateFlow models a single level of grouping: categories that hold spaces, with no sub-spaces beneath them.
That constraint is a feature. Deep hierarchies are where community content goes to die. Every level you add is another click, another decision about where something belongs, and another place a member can fail to find what they came for. Two levels โ category, then space โ is almost always enough, and communities that outgrow it usually have a consolidation problem rather than a nesting problem.
Use categories for the coarsest possible split: by member journey (Start Here / Learn / Connect), by product line, or by cohort. Not by topic, which is what individual spaces are for.
When to add a space
Add a space when there is already too much of something, never in anticipation of it.
The signal is concrete: a recurring topic is crowding out everything else in an existing space, or one identifiable group keeps having conversations that the rest of the community scrolls past. At that point the split relieves genuine pressure, and the new space arrives with a backlog of proven demand.
The failure mode is creating a space because a topic could exist. "We should have a space for job postings" is a hypothesis. Wait until people are already posting jobs in the main space and it is becoming a problem โ then move them somewhere with a name that says so.
One more test: if you cannot name three things that would be posted in the new space this week, it is too early.
When to merge or archive
Pruning matters as much as adding, and it is the maintenance almost nobody does.
Review your spaces quarterly with one question: has anything been posted here in the last 30 days? A space with no activity for a month is not neutral โ it is actively signalling that the community is quiet.
Merge when two spaces have overlapping purposes and neither has enough momentum. Combining two half-alive spaces usually produces one healthy one.
Archive when a space has genuinely finished โ a past cohort, a completed challenge, an event that has happened. Archiving keeps the content readable and searchable without leaving a dead room in the navigation, which is exactly what you want for anything time-boxed.
Tell people when you do this. Silently disappearing a space that someone was invested in reads as a decision made about them rather than with them.
Name spaces for behaviour, not for topics
Naming is structure. A good space name tells a member what to do there, not merely what it is about.
"Ask for Help" beats "Support." "Show Your Work" beats "Portfolio." "Start Here" beats "Welcome." The imperative version answers a question the member is actually asking โ what am I supposed to do? โ and a name that answers it gets used.
Keep names short enough to scan in a sidebar, avoid internal jargon that only your team understands, and be consistent: either all your names are imperatives or none of them are. Mixed conventions make a list of spaces feel like it was assembled by a committee, because it usually was.
Gating: who gets in
Structure and access are the same conversation, because a space's boundaries are what make it feel different from the rest of the community.
Beyond the public/private/secret setting, spaces can require approval โ requests arrive in a queue and you approve or reject them, which works well for spaces where fit matters more than volume. They can require payment, either as a one-off purchase or as part of a membership tier, so a paid space sits alongside your free ones without a second tool. And they can offer a preview, showing a limited number of posts to non-members so people can see what they would be joining.
The structural advice is to use gating sparingly at first. Every gate is a decision a member has to make, and a community with six locked doors on day one feels less like a place and more like a sales funnel. Start open, gate what genuinely needs it.
A worked example
A paid community for freelance designers, six months in, roughly 400 members:
Category: Start Here โ one public Feed space with the guidelines, the introductions thread, and a pinned how-this-works post. Public, because it is what a prospective member sees.
Category: Community โ a Feed space for general discussion, a Q&A space for critique requests, a Gallery space for finished work. All private: this is what the membership buys.
Category: Programs โ one Course space for the flagship program, one Feed space per active cohort, one shared alumni space. Cohort spaces get archived as each group finishes.
That is seven or eight live spaces supporting 400 people, which is roughly the right ratio. Note what is absent: no space per design discipline, no jobs board, no off-topic room. Those get added if and when the main spaces can no longer hold them.
The bottom line
Start with three to five spaces. Use Feed for most of them. Decide privacy carefully, because you cannot change it later. Group with one level of categories, never a hierarchy. Add a space only when an existing one is visibly straining, and archive the ones that have finished.
Structure is not a one-time setup task โ it is a quarterly review that takes twenty minutes and prevents the slow drift into fourteen empty rooms. Pair it with clear moderation and a deliberate onboarding path, and members will know both where they are and what to do.