should your community have its own app?
in reply to @alexbenzer.com, who asked builders whether people would want a separate app or site for their community
The honest answer is usually no — and the interesting part is why the exceptions are exceptions. A community-specific app is not a smaller Bluesky. It's a different shape of thing, and it only earns its existence when the community needs something the timeline structurally cannot give it.
Look at what people build on atproto once they stop trying to rebuild the main feed. Three recurring shapes:
If your community's needs don't hit one of those, a feed generator and a hashtag will serve you better than an app, and cost you nothing to maintain.
Even when it isn't strictly necessary, a dedicated space does something a hashtag doesn't: it makes the community legible to itself. There is a real difference between "people who use this tag" and "people who are here." The second has edges, and edges let a group form norms, onboard newcomers deliberately, and notice when someone's missing.
That's a social benefit, not a technical one — worth naming plainly, because it's usually the actual motivation and it often gets dressed up as a feature argument.
Everything else is downstream of these. They're listed in the order they bite.
The atproto answer is that they live in each person's own repo, on their PDS, and your app is a view over them. This is the choice that determines whether you've built a community or a silo. If your data lives only in your database, you've made a normal web app that happens to use Bluesky login — and when you lose interest, the community evaporates with it.
Define a lexicon. Write records to the user's repo. Let your app be rebuildable by someone else from public data. That constraint is what makes the thing durable past your own attention span.
You get this nearly free: people arrive as their existing handle, with their existing graph. Resist adding a second profile. The moment your app has its own display names and avatars, you've forked identity and taken on account recovery, impersonation, and moderation of a namespace you didn't need to own.
Community-specific attributes — a role, a rank, a location — are fine. Those are records about a person, not a replacement for them.
This is the one that sinks projects, and it's almost never planned for. Ask concretely: when someone posts something illegal through your app at 3am, what happens? If the answer is "I see it when I wake up," you have a moderation model, and it's you.
Labelers help, and inheriting upstream moderation covers a lot. But anything you render, you're answerable for. Smaller and slower is a legitimate design response — an app that only shows records from people you already follow has a much smaller bad-day surface than an open firehose view.
The failure mode is a beautiful app with four users. Because records live in repos, the strongest move is to make activity in your app visible from the timeline — posts that link back, records a feed generator can surface — so the main network is your funnel rather than your competitor.
An app nobody can stumble into is a group chat with extra steps.
Same four decisions, three very different scales. What changes is how much machinery each answer justifies.
| scale | shape | what it needs |
|---|---|---|
| a few dozen | One page, one lexicon, no server state. Members write records; the page reads them back. Moderation is "I know everyone." | A static site and a well-chosen record type. Genuinely a weekend. Most communities asking this question are here and don't realise it. |
| a few hundred | Now you need an index — reading every member's repo on page load stops being viable — plus a real sort order and some notion of newcomer onboarding. | A worker keeping a materialised view, fed from the firehose. Moderation becomes a role someone holds, not a thing that just happens. |
| thousands | A distinct product. Discovery, notifications, abuse handling, and the political work of governance. | Sustained staffing. If nobody's job is this, it will decay — and the decay is worse than never having built it, because people relocated their community into it. |
Build the smallest thing that answers a real structural need — a different unit, a different order, or a membrane. Put the records in users' repos so the work survives you. Inherit identity rather than forking it. Decide the moderation story before launch, not after the incident. And make the app visible from the timeline so it can actually find its people.
Most communities that ask this question want the third thing — the membrane, the sense of room — and can get most of it from a feed generator plus a shared tag, at a fraction of the cost. That's not a dismissal of the question. It's the part worth knowing before you spend three months.