Online community software features: the counted list from 60 real products
Most lists of community software features read like a product tour: spaces, posts, events, chat, badges, a mobile app. Every item is real, and none of them tells you what makes a community safe for its members to use, or what separates a working feature from one that only looks finished.
This list is counted. We read 120 official source pages across 60 community products — from creator memberships to company intranets, open-source forums and civic consultation platforms — and counted a capability only where a source documents it. For each feature you get the real version, the decorative one, and a test you can run on any community: a platform trial, open-source software, or something a developer or coding agent built for you.
The first thing the count shows
Spaces and groups are documented by 50 of the 60 products, and data export by 48. Then the list falls away exactly where members are most exposed. Roles and scoped access appear in 20. A reporting and moderation queue in 9. Privacy, blocking and messaging controls in 4. A moderation history with escalation in 1.
A community looks like the easiest product to build: spaces, posts, a member list, some events. What decides whether it works is who may read what about whom. The members are strangers to each other. Moderators handle reports about people they know. And the member directory is, underneath the avatars, a list of real people. The capabilities that govern all of that are the ones the market barely describes.
The nineteen, ranked
| Feature | Products (of 60) | Share |
|---|---|---|
| Spaces, groups, channels and collections | 50 | 83% |
| Articles, pages, resources, files and media | 48 | 80% |
| Data export, deletion, retention and compliance | 48 | 80% |
| Community guidelines, terms, consent and policy acknowledgment | 45 | 75% |
| Posts, discussions, comments, replies and reactions | 41 | 68% |
| Events, calendar, RSVP, reminders and attendance | 41 | 68% |
| Polls, surveys, ideas, voting and feedback | 41 | 68% |
| Single sign-on, API, webhooks, integrations and embeds | 41 | 68% |
| Search, tags, topics, follows, bookmarks and history | 40 | 67% |
| Direct messages, group chat, rooms and presence | 39 | 65% |
| Member home, activity feed, discovery and recommendations | 37 | 62% |
| Notifications with member preferences | 30 | 50% |
| Member identity, profiles, invitations, joining and onboarding | 27 | 45% |
| Points, levels, badges, streaks and reputation | 27 | 45% |
| Member directory, connections and matching | 24 | 40% |
| Roles, permissions and scoped access | 20 | 33% |
| Reports, flags, moderation queue and context review | 9 | 15% |
| Privacy, blocking, messaging controls and visibility preferences | 4 | 7% |
| Moderation audit history, escalation, assignments and SLAs | 1 | 2% |
1 · Spaces and groups — 50 of 60
Where the community is organised.
Decorative version: a list of rooms anyone can open. Real version: each space has a visibility — public, private or hidden — and a way in: open, request to join, or invitation only. A private space's posts never appear in search, the activity feed or the notifications of someone outside it.
The test: create a private space and post in it. Sign in as a member who is not in it and search for a word from the post. Nothing should come back.
2 · Posts, discussions and replies — 41 of 60
The conversation itself.
Decorative version: a feed of posts with a comment box. Real version: threads with replies, editing with a visible edit history, and deletion that follows the space's rules. A post in a private space stays private everywhere it could surface: the feed, search, email digests and notifications.
The test: turn on email digests for a member outside a private space, post in that space, and read the digest they receive. The post should not be in it.
3 · Events, RSVP and reminders — 41 of 60
Where many communities actually meet.
Decorative version: an event page with a date. Real version: time zones, capacity, RSVPs, reminders and attendance, with the event's visibility following its space.
The test: create an event inside a private space, then open the community calendar as a non-member. The event should not be listed.
4 · Direct messages and chat — 39 of 60
The most personal part of a community.
Decorative version: anyone can message anyone. Real version: members choose who can message them, can block someone, and a blocked member cannot reach them through any channel — messages, mentions or replies. Only 4 of the 60 products document privacy, blocking and messaging controls, so check them on anything you consider.
The test: block a test member, then try to message and mention yourself from that account. Neither should reach you.
5 · Notifications with member preferences — 30 of 60
What keeps members coming back, or drives them away.
Decorative version: an email for every post. Real version: each member chooses, per space, between instant notifications, a digest, or nothing, and every kind of notification respects the choice.
The test: set a space to "off" for a test member, then post in it from another account. Nothing should arrive.
6 · Member directory and profiles — 24 of 60
Who else is here.
Decorative version: a list of every member with everything their account holds. Real version: the directory shows what each member chose to share, and contact details stay private unless a member decides otherwise. A community manager's export of the member list is exactly as sensitive as the list itself, and deserves the same care.
The test: sign in as an ordinary member, then open the directory and a few profiles. You should see names and what members chose to show, not their email addresses.
7 · Roles and scoped access — 20 of 60
Who can run what.
Decorative version: two roles, admin and member. Real version: roles scoped to a space — a host who runs one group, not the whole community — plus moderators, with permissions checked on every action, including exports and reports.
The test: make a member the host of one space, then check they cannot manage a different space.
8 · Reports and the moderation queue — 9 of 60
How a community deals with problems.
Decorative version: a report button that sends an email to the founder. Real version: any member can report a post; only moderators can see the queue; the member who was reported never learns who reported them; each report shows its context, the post and the thread around it, and ends with a recorded decision. A moderation history with escalation is documented by just 1 of the 60.
The test: report a post as one member, then sign in as the member who wrote it. Nothing should tell them who reported it. Then check that an ordinary member cannot open the moderation queue at all.
9 · Data export and deletion — 48 of 60
What happens when a member, or the whole community, leaves.
Decorative version: an export button for the owner, and a "delete account" link that deactivates nothing. Real version: members can download their own data and delete their account; the owner can export the community; how long things are kept is written down.
The test: delete a test member's account, then check what happened to their profile and posts, and that the result matches what your terms say.
Which of these your community needs first
Nobody needs all nineteen on day one. What the community is for decides the order.
A discussion community — questions and answers that stay useful. Spaces, posts and replies, search and tags, notification preferences, and a report button with a real queue behind it.
A conversation community — real-time chat. Rooms, direct messages with member controls and blocking, and moderation that can act quickly, because chat moves faster than a queue.
An events community. Events with time zones and reminders, attendance, and member profiles people can use to find each other after a session.
A customer community beside your product. Single sign-on so members use the account they already have, ideas and voting, and roles for your own staff.
A paid community. Everything above plus paid access, which is a membership problem as much as a community one — see below.
What is deliberately not on the list
Paid access. Charging members for entry is a membership problem with its own list: membership management software features.
Courses. Lessons and progress tracking belong to a learning platform; see features of a learning management system.
Livestreaming and video hosting. Usually handled by specialist tools and embedded; 41 of the 60 document integrations and embeds.
The requirements list you can hand someone
- Spaces with a visibility (public, private, hidden) and a way in (open, request, invite).
- Private content that stays private in search, feeds, digests and notifications.
- Events whose visibility follows their space, with time zones and reminders.
- Members control who can message them; blocking works in every channel.
- Notification choices per member, per space: instant, digest or off.
- A directory that shows what members chose to share, never their contact details by default.
- Roles scoped to a space, with every permission checked on every action, exports included.
- Reports any member can file, a queue only moderators can see, and reporters who stay anonymous to the member reported.
- Members can export their own data and delete their account.
- Branches chosen in writing: [discussion / chat / events / paid access / customer community].
Why AI-built community software misses these
Ask a coding agent for a community and it will build all of the visible parts in an afternoon — spaces, posts, a member list, events — and it will look finished.
What it will not have decided is who may read what about whom: whether the directory shows addresses, whether a private space stays private in search and email, who can see a report. Left to defaults, those answers are often "everyone can see everything", and nobody notices until a member does.
When three AI models built the same community specification, that question decided the board. All three builds are live on the online community demo page.
If you are weighing a free plan first, free online community platforms covers what free plans hold back and six tests to run before you invite anyone.
If you are pointing a coding agent at this, the Online Community planner is the specification we hand ours: this inventory, and who may read what about whom decided before any code is written.