Plansmith
Online Community

Online Community Planner

Research-backed planner built from a 60-product census of online community software across 120 official source pages — a community where members are strangers, moderators judge reports about people they know, and the directory is a list of everyone's contact details.

v1.0.060 sources · frequency-ranked

The problem this kills

A community looks like the easiest product in this catalogue. Spaces, posts, replies, a member list, some events. Ask a coding agent for one and it will build all of that in an afternoon, and it will look finished.

What it will not have decided is who may read what about whom. The members are strangers to each other. Moderators handle reports about people they know, and the person reported must not learn who reported them. The member directory is, underneath the avatars, a list of real people's contact details — and a community manager's export of that list is exactly as sensitive as the list itself. The naive build shows the directory to every member with the email addresses left in, guards the export, and never notices that the two paths serve the same rows.

What the research changes

The planner carries a frequency-ranked capability inventory from 60 real products — Circle, Mighty Networks, Discourse, Khoros, Salesforce Experience Cloud and 55 others — read across 120 official source pages, stratified from creator memberships to enterprise intranets, open-source forums and civic consultation platforms.

The inventory shows where public marketing goes quiet. Spaces and groups are documented by 50 of 60 products and data export by 48. But the reporting and moderation queue appears on only 9 of 60 pages, privacy and visibility controls on 4, and moderation audit history and escalation on 1. Roles and scoped access reach just 20. The capabilities a buyer's members will actually depend on are the ones the market barely describes, so the planner raises them on lifecycle dependency instead of frequency.

What it makes the agent decide

  • Which fields of a member one member may read about another, and whether an email address is ever one of them.
  • Whether an export re-derives its rows from the same scoped query as the screen it exports, or becomes a second, unguarded copy of the directory.
  • Whether a reported member can ever learn who reported them — through the queue, a notification or a history screen.
  • What a member who hides themselves from the directory hides from: other members only, or staff as well.
  • Whether a denial says not-found or forbidden, so a member cannot confirm a private space exists by reading a status code.
The inventory · 01

The frequency-ranked ledger.

Feature
Prevalence across 60 tabulated community products
Sources
Freq.
Spaces, groups, channels, and collectionsThe most evidenced capability in the category and the unit most permissions hang off. A private space has to stay invisible to a non-member everywhere — its list, its search results and its direct URL.
50/60
83.3%
Articles, pages, resources, files, and mediaA file is only as private as the space it sits in. Download routes are the classic place a visibility check gets forgotten.
48/60
80%
Data export, deletion, retention, and compliance custodyDocumented by 48 of 60 — and the capability most likely to become a second copy of the member list. An export has to come from the same scoped query as the screen, or it is a leak with a download button.
48/60
80%
Community guidelines, terms, consent, and policy acknowledgmentConsent is a record, not a checkbox: which version a member accepted, and when. A guideline change that should require re-acknowledgment has to be able to say so.
45/60
75%
Posts, discussions, comments, replies, and reactionsThe core surface. A report has to identify the exact reply it concerns, not just the thread, or a moderator acts on the wrong contribution.
41/60
68.3%
Events, calendar, RSVP, reminders, and attendanceAttendance lists carry names and contact details, so the attendee export belongs to the host of that event and to staff — not to every member who can see the event.
41/60
68.3%
Polls, surveys, ideas, voting, and feedbackA vote is attributable data. Whether results show who voted is a decision, not a default.
41/60
68.3%
SSO, API, webhooks, integrations, and embedsEvery integration is another read path. An API that returns what the screen hides has undone the screen's permissions.
41/60
68.3%
Search, tags, topics, follows, bookmarks, and historySearch is where private spaces leak by accident — a result snippet from a space the searcher cannot open is still a disclosure.
40/60
66.7%
Direct messages, group chat, rooms, and presencePrivate by definition. Moderation of a message must not become a way for staff to read every conversation.
39/60
65%
Member home, activity feed, discovery, and recommendationsA feed built from everything is a feed that shows members what they should not see. It has to be assembled from what the reader may already read.
37/60
61.7%
In-app, email, and push notifications with member preferencesA notification carries a snippet of its source. Telling a member their report was reviewed must not tell the reported member who filed it.
30/60
50%
Member identity, profiles, invitation, join, and onboardingThe entry path. An applicant is signed in but not yet a member, and must see nothing a member sees until they are approved.
27/60
45%
Points, levels, badges, streaks, and reputationReputation is public by design, which is exactly why it must be computed only from activity the viewer is allowed to see.
27/60
45%
Member directory, profiles, connections, and matchingOnly 24 of 60 document it, and it is the vertical's defining confidentiality surface: a directory of strangers. Name, headline and shared interests are a feature; an email address is a mailing list.
24/60
40%
Roles, permissions, and scoped access20 of 60. The substrate everything above depends on, and the most under-described capability that matters. A community manager is not simply a member with more buttons.
20/60
33.3%
Reports, flags, moderation queue, and context reviewOnly 9 of 60 describe it publicly, yet every community needs it. The queue carries reporter identities, so it is staff-only — and so is every export of it.
9/60
15%
Privacy, blocking, messaging controls, and visibility preferences4 of 60. Hiding from the directory has to say what it hides from — other members, or staff too — because members will assume the answer.
4/60
6.7%
Moderation audit history, escalation, assignments, and SLAs1 of 60. The record of who decided what about a member is the record a moderator's decision is later judged by, so the planner treats it as required rather than inferring it from a queue.
1/60
1.7%
See it in action · 02

Real apps this planner built.

A directory that never hands out an address — live demoLive
Built by Claude Fable 5.1

A directory that never hands out an address

“Hearthside” — the highest-scoring build of the three, and the one that treats the member directory as what it is: a list of real people who are strangers to each other. The directory never selects an email address at all, and the same visibility rule guards the list, a profile opened by its id, a member's connections and search, so there is no second door into what the first one withholds. A member who hides from the directory answers not-found rather than forbidden. The member list and its export are refused to ordinary members and hosts alike. You land on the community's public page; choose Sign in and pick a role — community manager, moderator, member or host. Those buttons are switched on deliberately here, run through the same session service as a password sign-in, and in production the build keeps them off even if the setting is left on.

Open live demo
The most defended build in the programme — live demoLive
Built by GPT-6 Astra

The most defended build in the programme

“Gatherwell” — the only build of the three that throttles sign-in attempts, and one that refuses any change that does not come from its own origin. Retried requests are replayed rather than applied twice, concurrent edits are caught instead of overwriting each other, and every audit entry is written in the same transaction as the change it records. The member list and its export are literally the same request, so they cannot drift apart. It arrived with two operational faults — deleting its database stopped it from starting, and its own test suite could not be re-run against what it delivered — and both were repaired and re-verified, so it was rescored 92 → 97; this is the repaired build. You land on a sample community's public page; choose Sign in and pick a role. The role buttons are the build's own, switched on for this sample environment.

Open live demo