Look at how any established community actually operates and you'll find a chat group surrounded by a small archaeology of workarounds.
A shared spreadsheet for the member list. A form for the summer trip. A Drive folder nobody can find. A calendar two people subscribe to. A pinned message that's four months out of date. Each of these was added by a sensible person solving a real problem, and together they're the reason running the community feels heavier than it should.
The pattern is worth naming, because it isn't a failure of organization. It's what happens when you use a tool that does one job for a situation that has five.
Chat is the beginning, not the system
Conversation is genuinely the foundation. A community without talk is a mailing list. The chatter, the in-jokes, the photos from Saturday: that's where belonging actually forms, and any tool that treats it as a distraction has misunderstood the job.
But a chat stream has one defining property. It moves. Everything in it is ordered by when it was said and buried by whatever was said next. That's perfect for conversation and wrong for everything that needs to stay put. We've catalogued what that costs a club in practice in the hidden cost of running your club on WhatsApp, and the same erosion shows up when a Facebook group stops keeping up.
The five jobs
1. Conversation
Talking, reacting, asking, joking. Needs to be fast, informal and in the moment. Chat is excellent at this and there's no reason to replace it.
2. Gathering
Getting specific people to a specific place at a specific time. This needs a date, a location, a list of who's coming, and reminders that arrive without anyone remembering to send them. An event isn't a message about an event. It has a state that changes, and it needs to be somewhere you can check rather than somewhere you scrolled past. For the weekly version of this problem, see running a recurring event without losing your mind.
3. Memory
The constitution, the minutes, the risk assessment, last year's accounts, the photos from the anniversary dinner, the document explaining how the raffle works. Communities generate surprisingly durable records, and their default home is one committee member's laptop.
The test for memory is simple: can somebody who joined last week find it without asking anyone? In most communities the honest answer is no.
4. Membership
Who's actually part of this. Not a list of phone numbers, but a list of people, with some structure: who's on the committee, which team they're in, who joined recently, who quietly stopped coming.
This is the job that gets skipped most often, and it's the one that makes everything else harder. Without it you can't reliably reach everyone, welcome anyone properly, or answer basic questions about your own community.
5. Permission
Who's allowed to do what. Who can post an announcement, cancel a session, add a member, see the finance folder. Volunteer organizations tend to have exactly two settings here, one admin or everybody, and both cause problems. There's a middle worth designing on purpose, which we've laid out in a guide to roles and permissions.
Why the bolt-on approach fails
Nothing above is exotic, and for each job there's a good free tool. So why doesn't assembling them work?
Because the jobs aren't independent. An event needs to know who your members are. A permission needs to apply to a group. The files belong to the trip, which has its own conversation and its own attendees. When those live in five systems, the connections between them have to be maintained by a human, and that human is a volunteer with a day job.
That maintenance is the actual work of running a community on assembled tools. Copying the member list into the form. Re-sharing the folder with the new coach. Reminding the chat that the calendar exists. It never appears on anyone's list of responsibilities and it consumes most of the effort.
The integration tax
There's a second cost, paid by members rather than organizers. Every extra tool is another place to check, another login, another notification setting, another thing to be confused by.
The predictable outcome is that members ignore most of them and use the chat for everything, which is how you end up with people RSVPing to a form by replying in WhatsApp. Members aren't being difficult. They're routing around complexity, as anyone would.
If your community's information lives in five places, in practice it lives in whichever one people already have open.
What "one place" should actually mean
The point of one place isn't that a single tool has the most features. It's that the five jobs know about each other.
A group has its own conversation, its own events, its own files and its own leads. An event knows who's coming because it knows who the members are. A permission is something you grant inside a group rather than a spreadsheet of exceptions. Nobody has to copy anything from one system to another for the whole thing to stay true.
That's the difference between a tool with a calendar bolted on and a community platform. It's also, honestly, the harder thing to build, which is why so much community software is chat with extras.
Reading on from here
We built Joyn around those five jobs rather than around a chat window, which means it does some things general-purpose tools don't, and deliberately doesn't do some things they do well. Rather than claiming to win everywhere, we've written each comparison out properly:
- Joyn vs WhatsApp groups, for when informal chat stops being enough
- Joyn vs Facebook Groups, on reach, member records and who owns the audience
- Joyn vs Basecamp, on why a community isn't a project, and where Basecamp still wins
If you'd rather see the shape of it than read about it, the features page walks through how spaces, groups, events, files and roles fit together.