Class 68 gave you an audience: people who return because you keep solving a recognizable problem. Class 69 asks the next question — will those people ever talk to each other? If the answer is no, you have traffic, not a community. This lesson draws that line cleanly and gives you a purpose test before you rent a Discord server you cannot fill.

Traffic visits. Community returns to each other.

An audience is one-to-many. You publish; they read, watch, or buy. The relationship runs through you. A community is many-to-many. Members recognize names, answer each other's questions, bring problems you did not assign, and return partly for each other. The relationship runs through shared practice.

That difference changes everything you measure. Traffic cares about views, clicks, and conversions. Community cares about repeat participation: how many people came back this week, how many replied to someone other than you, how many threads continued without you. A newsletter with 10,000 silent readers is a strong audience. A forum with 80 people who help each other every Tuesday is a strong community. Confusing the two is why so many "communities" are empty chat rooms attached to healthy audiences.

Think of a tailor's shop from Class 68. The audience is everyone who reads the "same-week hemming, honest prices" posts. The community — if one is warranted — is the dozen local event planners, brides, and theater-costume volunteers who swap rush-job referrals, fabric sources, and fitting tips in a small group. They do not just need the tailor. They need each other, repeatedly.

The repeated-interaction test

Before you build anything, run three checks:

1. Is there a recurring shared job? Members must have a reason to interact more than once. "People who bought my template" is a one-time fact, not a recurring job. "Solo analysts turning filings into briefs every week" is recurring — each week brings a new filing, a new edge case, a new question.

2. Can members help each other, not just you? If every question can only be answered by you, you need office hours or a better FAQ, not a community. A community works when member A has solved something member B is stuck on. Analysts can compare sources. Home bakers can diagnose a collapsed loaf from a photo. Peer help is the engine; your answers are the starter motor.

3. Will interaction compound? Each conversation should make the next one better: answered questions become a searchable archive, shared templates improve, reputations form. If every discussion evaporates — the same beginner question asked weekly with no memory — you have a support queue, not a community.

If you fail any check, do not build a community yet. Keep building audience. The kindest thing you can do for future members is to wait until repeated interaction is genuinely possible.

The purpose test: one paragraph, five sentences

If you pass, write a purpose statement with exactly five sentences:

1. Who: the specific people (borrow your NICHE-PORTRAIT.md from Class 68). 2. Recurring job: what they do together, weekly or more often. 3. Interaction: what a good exchange looks like (ask, show work, critique, compare). 4. Outcome: what a member can do after three months that they could not do alone. 5. Not-this: what the community explicitly is not (no job board, no hype, no guru Q&A).

Example — research builders:

That final "not-this" sentence does most of the moderating before moderation exists. It tells you which threads to redirect and which members to disappoint early, kindly.

Why this lesson comes first

Every later choice — home, seeding, norms — depends on purpose. A debugging community needs threaded, searchable Q&A. A practice community needs show-your-work rituals. A local referral community needs trust and identity. Pick the format from purpose, not from where you personally hang out. Lesson 69.2 does exactly that comparison.

A real-world caution: many failed communities were launched to serve the founder's distribution goal ("I need engagement") rather than a member job. Members sense that instantly. The purpose statement forces you to state the member job first. If you cannot state it, the market is telling you something.

Exercise: write and stress-test the purpose

Draft PURPOSE.md with your five-sentence statement, plus three beam lines:

• Three threads you hope to see in week one (write their titles).
• Three threads you will redirect or remove (write those titles too).
• The repeated-interaction evidence: name one recurring job, one peer-help example, and one compounding artifact.

Finish line: a five-sentence purpose plus six example thread titles that make the boundary concrete.

Verify quickly: show it to two ideal members and ask "would you post here weekly?" If they ask "post what?" — your recurring job is still vague. Sharpen it.

Common failure mode: a purpose that promises everything ("learn, network, grow, get clients"). Every clause you add halves the chance anyone knows what to do on day one.

Check your understanding

1. What is the structural difference between an audience and a community? 2. What are the three checks in the repeated-interaction test? 3. Why does the purpose statement need an explicit "not-this" sentence?

Next

Purpose is decided. Lesson 69.2 picks the right home for it — website, forum, Discord, Slack, newsletter, or social — staged so you do not pay for infrastructure before interaction exists.