Every Client Wants a Community: The Scope-It-Before-You-Build Guide

Summary

On the first kickoff call, nearly every membership client says “we want a community” — and that phrase can quietly expand the project into a portal with forums, events, courses, and live rooms nobody will use at launch. This article gives agencies a repeatable scoping conversation for turning that vague request into a small, shippable membership site. It starts with the sentence test (“members pay because they get ___”), forces the client into one business model, defers community features until there’s a real audience, and treats every feature request as a change order. The article includes one worked example of a client who wanted a full community and launched a searchable archive plus a monthly live Q&A instead. It also warns against promising engagement: you can deliver the door, but you can’t make people walk through it. The result is a product line instead of a rescue mission, and clients who thank you for what you refused to build.

On the first kickoff call, the client says, “We want a community.” You nod, type the word into your notes, and feel your roadmap quietly double. Because “community” can mean a forum, a private chat group, a paywall, a course library, an event series, a member directory, or all of the above. Let it mean all of the above and you’ll spend a quarter building things nobody uses, then bill the client for watching them not use it. The fix isn’t a cleverer platform. It’s a more honest conversation, run the same way every time, so that your next seven clients don’t each become a one-off bespoke project.

This piece is built around the questions we actually keep answering on this work. Not “which tool should we use” — that comes after — but the questions that decide whether a project ships on time, stays profitable, and leaves the client feeling like you knew what you were doing.

“We want a community” — what are we actually selling?

Get the client to finish one sentence before you even mention platforms: “Members pay us because they get ___.” That’s it. If they can’t fill in the blank with something specific, you’re not ready to choose a platform, sketch a page, or quote a price. The entire membership site — the paywall, the tiers, the features you leave switched on — is just the delivery mechanism for that answer.

What most clients are really buying when they say “community” tends to fall into four buckets. When we scope repeatably, we force the decision into one of them:

What members pay for	The part you actually build	The part you can safely defer
Content (courses, archives, tools)	Gated library, payment flow, basic player	Live rooms, event calendars, certificates
Access (a product, service, or tool)	Member login, entitlements, account gates	A public-facing forum and social feed
Connection (peers, accountability, networking)	One discussion space, profiles, invites	Full course platform, content drip, certificates
Status (insiders, early access, exclusive perks)	Tiered access, badge/label logic, simple perks	Forums, user-generated content, live events

The table is a scoping cheat sheet, not a menu. The client gets one bucket. If they try to merge two, you should raise your hand and slow down, because your costs just went up. The trap is doing all four for one client and calling it “an engaged community platform.” That’s not a product; that’s a portal, and portals don’t launch on time.

This table is deliberately small. The moment you let a membership site be four things at once, you’ve stopped building a product and started running a small media company. The client rarely wants a media company; they want recurring revenue. Keep the scope small enough that the revenue model is visible from the homepage.

When a client says “course” and “forum” in the same sentence, ask which one pays the bills. If the answer is “both,” you’re actually seeing a client who doesn’t know what they’re selling yet. Some of them figure it out during scoping and come back with a clearer offer; the ones who don’t are telling you they’re not ready. That’s a useful thing to learn before you write a proposal, not after.

But they’ve already said “community” a hundred times

Here’s the contrarian bit, and it’s not a humble-brag: most membership sites should not launch with community features at all. “Community” is not a feature. It’s a behavior that emerges when a small group of people get recurring value from each other, and no platform can produce that on demand. The word has become a stand-in for “subscription revenue,” which is why every client says it. You’ll be more useful to them by translating it back.

Run a community reality check before you let the scope grow. Ask three questions:

1. In the first week, what exact behavior do you want a new member to do? (Not “engage” — “post an introduction,” “leave a comment,” “finish the first lesson.”)
2. Who on your team will spend time in this space during the first month, replying, steering, and clearing the clutter?
3. Is there already a handful of people who have this problem and know each other, or are you hoping strangers will become a team because the website exists?

If all three get vague answers, you’re not building a community; you’re building an empty room and calling it architecture. The practical move is to defer every community feature and launch the membership skeleton instead. You can always add a discussion space later, and when you add it to a group that already has reasons to show up, it has a chance of working. The whole question deserves a longer treatment — community should come after you’ve got real members — but the one-sentence version is: don’t build the amphitheater before the audience exists.

What’s the smallest thing that could possibly work?

Once you’ve classified the offer, design the launch as a skeleton. One payment option, one tier, one gated asset, one communication loop. Take your platform’s feature list and switch everything else off. Yes, the platform can do live video rooms, member profiles, event management, and analytics dashboards. That’s the problem.

A client came to us with what they called a full community vision for their B2B SaaS product. They’d been talking about forums, an event calendar, a resource library, and a “member spotlights” section. During scoping we made them finish the sentence: “Members pay because they get ___.” Their answer was a searchable archive of the founder’s advice plus a monthly live Q&A. So that’s what we launched. No forum, no member profiles, no event calendar. Not long after, the archive was being used, the Q&A had regulars, and the client asked for a private discussion group because members were already talking to each other outside the product. The group got built after it had a reason to exist. That’s the order that works.

If we had built the full vision, we’d have launched late, with more moving parts and no way to tell which one actually created the habit. The archive could point to a real behavior; a live room that never got used would have just been a bill. The lesson is boring but reliable: the smaller the launch, the more likely the client will be able to tell you what’s actually working. A slim product also gives you room to do the next thing well — add a tier, open a forum — as a deliberate change order rather than a rushed extra squeezed into launch month. If you’re looking for a repeatable way to think about tiers and revenue structure, that’s the piece on membership tiers for recurring revenue, but scoping comes first.

What happens when the requests pile up?

Let’s be honest about how most membership projects die: not from incompetence, but from “one more thing.” The client sees a demo of a competitor’s community and wants a matching feature. The right response is not “yes” and not “no” — it’s “let’s add it to the deferred list.”

Make the deferred features list a first-class deliverable in your project. Put it in the proposal, keep it visible, and append every out-of-scope request to it. Give each item a trigger condition. Not “someday” but “this ships when 200 active members have been in the space for a month” or “when the client commits two hours of staff time per week to moderate it.” You’re not being difficult; you’re giving the feature a reason to exist.

This is how you stop rebuilding the same membership site for every client: by treating every new client as a configuration of a skeleton you’ve already shipped, with a list of things you intentionally didn’t build. If a feature is on the deferred list, it’s a future project, which is also future revenue. Frame it that way and the client will usually agree.

How do we keep the client from blaming us for the empty forum?

You need to set expectations about what you can and can’t control, early and in writing. You can deliver the payment flow, the gating, the email automations, and the design. You cannot deliver people deciding to talk to each other. The client’s “engagement problem” is not a build problem; it’s an operations problem, and it belongs in their lap.

This matters because clients will quietly start asking why “the community” is quiet three weeks after launch. If you set the boundary from the start, you can have a useful conversation about incentives and seeding. If you didn’t, you’ll be debugging a platform that isn’t broken. A practical way to formalize it: include a separate line item for “community hosting and seeding” in your maintenance retainer, or hand the client a seeding checklist that lives in their project kickoff. The point is to make the division of labor explicit. The tool isn’t the retention strategy; the membership site myths are usually the culprit when people expect a platform to do their selling for them.

When they insist on a community anyway, what do we turn on?

If the client clears the reality check and is genuinely operating a community, flip on exactly one discussion format. Not three. A forum is threaded, searchable, and asynchronous; a live room is immediate, ephemeral, and staff-hungry. You can’t moderate both well with a small team, and trying to do so will teach your client that “community” means constant activity, which is a standard you shouldn’t promise.

Practical rule: one space, one format, one named moderator. Pick the format that matches the behavior you identified in the reality check. If the desired behavior is “answer a question and get an answer,” start with a forum. If it’s “show up on Tuesday at noon to talk through challenges,” start with a live event. Then set a lightweight metric for the first ninety days: not total members, not signups, but the number of members who did the target behavior at least twice. Two mentions of activity is enough to know whether the space is alive or a museum.

How do we price this so it’s a product line, not a rescue mission?

Make the discovery conversation itself a billable product. Create a fixed-fee membership site setup package that includes the scoping call, the skeleton build (yes, really), payment configuration, and one round of revisions. Everything beyond that — community design, custom features, moderation hours, integrations — is a separate statement of work. That’s the whole trick. When you quote each optional feature as a change order, the client suddenly learns to prioritize. When you bundle everything into one escalating estimate, you teach them that more scope is free.

A repeatable process looks like this: a questionnaire you send before the call, a one-page statement of work with a fixed price, a build schedule your team has run before, and a template for the deferred features list. You should be able to tell the client the go-live date before the design moodboard exists. You also get a better conversation: the client sees what the bare minimum costs, what the community extras cost, and what their own time costs. If they balk at paying for a skeleton, you’re about to learn that before it hurts.

The part nobody wants to hear

Every membership site is a bet on a recurring behavior. The platform is just the envelope. Your job, as the person who builds this for many clients, is to get the envelope addressed and stamped while making sure no one has signed up to deliver a live performance by hand. You can’t make a community happen. You can create the conditions, choose the smallest possible version, and hand the client a clear list of what you’re not building.

That last part is your real value. The client hired you because they can’t see what to leave out. So leave it out for them — confidently, on purpose, in writing. Once you’ve scoped, the delivery becomes almost boring: membership site launches actually ship when they’re small and the decisions were made up front. Empty forums and sprawling custom portals are expensive. The skeleton, on time, is worth far more than the “powerful community platform” that never quite launched.