How to Launch a Discord Community Before Your Product Is Ready

The readiness test, stated first

A pre-launch Discord community

is ready to open publicly when you can post something new twice a week that is not a countdown. Before that point, keep it private, keep it small, and keep it working.

The reason is behavioural. A room teaches arrivals how to act by what they see happening in it. If the only recurring event is a date getting closer, the room teaches people to read and never write, and that habit follows them to launch day.

What most teams build instead

The usual sequence: announce the waitlist, open a server the same afternoon, create ten channels in anticipation of growth, and post progress updates whenever there is something photogenic.

By month three that server holds a few hundred silent members and a founder who has concluded that communities do not work for their category. The structure caused the outcome. Ten channels among two hundred quiet people produces the visual impression of an abandoned building, and nobody speaks first in an abandoned building.

The run, four weeks, in order

Weeks are cheap right now. Use them in this order.

1. Invite twenty by hand and ask one question. The question points at their current workaround rather than at your roadmap. What are you doing today instead of using this? produces a problem list. Any question about your product produces compliments, which are pleasant and useless.
2. Run a weekly change log with names in it. Post what moved, who prompted it, and what you are weighing next. Fifteen minutes a week, and it is the entire retention mechanism at this stage.
3. Hand out jobs earned by behaviour. Early tester, reviewer, room host. Give each one to somebody already doing the work unpaid, so it lands as recognition.
4. Design the arrival path, then write the launch post. One landing room, a named greeter on a shift, and one two-minute action that gets a human reply.

A rehearsal beats a plan. On the Friday before launch, have a member bring in one outsider and watch that person without stepping in. What stalls them is what will stall your launch traffic, and you have a weekend to fix it.

Why the change log carries everything

Members of a pre-product room are being asked to invest attention in something that does not exist. The only honest return you can offer is influence, and influence has to be visible to count.

A suggestion that quietly becomes a feature builds nothing. A suggestion that becomes a feature with the member's name attached builds a room where being useful is worth doing in public.

When a week produces no shipped change, publish a decision. Explain what you decided not to do and why. Early members find that more interesting than progress screenshots, because it tells them how the company thinks, which is the thing they are really evaluating.

The wrong metric, and the two right ones

Counting members before launch measures your marketing reach and nothing about your community. It also creates a trap, because the number goes up while the room gets quieter, and the eventual correction looks like failure.

Use two numbers. The count of product decisions the room caused, which the change log has already documented for you. And the share of invited members who posted in the last fourteen days, which is the only early warning you get before a room goes cold.

Bring both to the launch review. They are the numbers that justify the layer of work that comes after launch, and they are much harder to argue with than a member count.

After the doors open

The run above ends on launch day, and launch day changes the job. Volume arrives, questions repeat, and the room that twenty people kept warm now has strangers in it who owe you nothing.

Two things carry over well. The change log keeps running, now doubling as a product update channel that gives returning members a reason to open the app. The named jobs keep working, because the people holding them are the ones who make a busy room feel supervised to a nervous newcomer.

One thing changes immediately. Greeting duty stops being a favour and becomes a rota with hours attached, because the first reply a stranger waits for on launch day sets their opinion of the whole product.

The layers above this one

A four week pre-launch run is one layer of community infrastructure, and one person can execute all of it.

The larger system it belongs to is what launch volume demands: role and channel architecture built for ten times your current size, an onboarding sequence that runs across the first three weeks rather than the first message, support routing with a defined escalation path, moderation coverage that holds overnight, an owned weekly rhythm, and reporting that ties the room to product decisions and revenue. Designing those on a room of twenty costs a fraction of what it costs to retrofit them on a room of twenty thousand, which is the strongest argument for doing the pre-launch work properly.

Post the first change log this week. Name somebody in it.

Anticipation fades on schedule. A record of what your members changed does not. Written from the build side at danieljeong.org.