How to Launch a Discord Community Before Your Product Is Ready
The four week run that turns a pre-launch room into an asset instead of a countdown feed, and the one rule that tells you when to open the doors wider.
| Open a pre-launch community only when you can post something new twice a week that is not a countdown. Until then, keep it private with about twenty invited members, run a weekly change log that names the member behind each change, and spend the last week building the arrival path for launch day. |
|---|
Open it when you have news twice a week
How to launch a Discord community before your product is ready: keep it private and small until you can post something new twice a week that is not a countdown, then open it with an arrival path already built. That rule does most of the work, and it is worth applying before anything else on this page. A room with news twice a week feels like a place where things happen. A room with a countdown every Friday feels like a mailing list with extra steps, and members treat it accordingly. The four week run below is what fills those two slots a week while the product is still being built.
What a pre-product room is actually for
The assumption worth dropping first: a pre-launch community exists to build anticipation. Anticipation is a feeling, and feelings do not survive a delayed release date. A pre-launch room earns its keep by producing two things you can point at in a leadership meeting. The first is a list of problems in your buyers' own words, gathered before you have committed engineering time. The second is a group of people who know each other and know you, which is the only thing that makes launch day traffic stick rather than bounce.
A room where members can see their words changing the product does not need hype. It has evidence.
Week one: twenty people and one question
Invite about twenty people by hand. Not the waitlist. Twenty specific people who have the problem badly enough to talk about it on a Tuesday. Put one question at the door and make it a question about their current life rather than about your product:
*Door question: "What are you doing today instead of using this?" Why this question works pre-launch:*
- It cannot be answered with praise
- It produces a list of the tools and workarounds you are really replacing
- The answer sorts people into groups you can talk to differently later Keep the structure minimal. One room for conversation, one room where you post updates. Two channels and twenty people beat twelve channels and two hundred every time at this stage. Spend the week reading rather than pitching. Your output for week one is a written problem list, ordered by how many people raised it without prompting.
Week two: the change log is the engine
Start posting what changed, weekly, in a dedicated room, and name the member whose comment caused each change. This is the mechanism that keeps a pre-product community alive, and almost nobody runs it. The post takes fifteen minutes and reads like this: three lines on what moved, one line each on who prompted it, and one line on what you are looking at next. Naming people is the part that does the work. It converts a suggestion box into a place where being useful is visible to everybody else in the room. Members do not stay for the product. They stay because their fingerprints are on it. When there is no engineering change to report, report a decision instead. A decision not to build something, with the reasoning, is more interesting to an early member than a screenshot of a button.
Week three: jobs with names
Give people something to be, and tie it to work rather than to purchase.
| Job | What the person actually does | What it gives you |
|---|---|---|
| Early tester | Uses the build weekly and reports what broke | Bug reports before strangers find them |
| Reviewer | Reads drafts of docs and onboarding copy | Launch materials that survive first contact |
| Room host | Welcomes arrivals and answers repeat questions | A greeting that does not depend on you |
Two cautions. Give a job to somebody who has already done the work informally, so the role reads as recognition rather than as a chore assignment. And keep the number of jobs small, because a room of twenty with five roles starts to feel like an org chart. By the end of this week you should have a room host who is not on your payroll. That single person is what makes the next week possible.
Week four: the arrival path for launch day
Write the arrival path before you write the launch post. Most teams do it the other way around and discover on the day that traffic landed in a room with nothing to do in it. Three questions, answered concretely:
- Where does a person from the launch post land? One specific room, not the server's default. That room should contain the one thing a stranger needs, and nothing else.
- Who greets them inside ten minutes? A named person on a named shift, covering the hours your traffic will actually arrive. Your room host from week three takes a shift.
- What do they do before they close the tab? One action, achievable in two minutes, that produces a visible response from another human. Introducing themselves works only if somebody replies. Run a rehearsal. Ask a member to invite one outsider on the Friday before launch, then watch what that person does without helping them. Whatever confuses that one stranger will confuse three hundred.
The two numbers to carry upstairs
Member count is the wrong metric for a pre-launch room and it will get you defunded when growth flattens. Carry these instead. First, the count of product decisions traceable to the room, which you already have written down because the change log names them. Second, the share of your invited members who posted in the last fourteen days. A room of twenty with fourteen active is healthy. A room of two thousand with fourteen active is a launch problem you have not met yet.
What to do when the launch date slips? Say so in the change log, in the same post format as everything else, with the reason and the new date. A pre-launch room survives a delay easily. It does not survive three weeks of silence followed by an apology, because silence is the thing members interpret as a signal about the company.
Where this sits in the larger system
The four week run is one layer, and it is genuinely enough for the pre-launch window. Everything in it can be built by one person with a calendar. What sits above it is the operational build that launch traffic forces: channel and role architecture designed for the size you expect to reach, an onboarding sequence that runs past day one, support routing with a written escalation path, moderation coverage that holds overnight and across regions, an engagement rhythm somebody owns week to week, and reporting that connects the room to product and revenue. Pre-launch is the cheapest moment to design those, because you are choosing on a room of twenty rather than migrating one of twenty thousand. Start with the door question and the change log. Post the first one this week, name a member in it, and see what the room does.
The rooms that hold on launch day were doing something the month before. Usually something small, posted weekly, with somebody's name in it. More at danieljeong.org.