How I Work: The Company, the Avatar, and One Sentence That Runs the Whole Server

Community builds fail when they start with channels. Every engagement I run begins with three fixed decisions: what the business actually sells, who actually shows up, and one sentence naming what the server is for. Structure, onboarding, and automation come afterward, and each piece has to earn its place against that sentence.

Nobody actually wants a Discord server

Companies do not want a server. They want the thing a server can produce. Fewer support tickets. Users who stay past week two. A place where the people who already love the product can find each other so the team stops being the only source of energy. The server is the machinery. It is not the point. When a build starts with the machinery, you get a room that looks impressive on a screenshot and does nothing for the business, because nobody ever wrote down what it was supposed to do. So the first thing I do on any engagement is refuse to talk about channels.

First the company, because community is downstream of the business model

Before I look at a single permission setting, I want to understand how the company makes money and where a community could plausibly sit inside that. A developer platform and a consumer creative tool both benefit from Discord, and almost nothing about the two builds should look the same. One needs a support surface with searchable answers and a path from confusion to a working integration. The other needs a place where people post what they made and get seen for it. Same product category on paper, completely different room. I ask a short list of questions and I care about the answers more than the tooling:

• What does someone buy, and what has to be true before they buy it
• Where do people currently get stuck, and who absorbs that today
• What does the team already do manually that a system should be carrying
• What would make leadership consider this a success in six months That last one gets a vague answer more often than not, which is useful information on its own. If nobody can define success, the server will end up measured by member count, and member count is the least honest number in community work. It goes up when a campaign runs and tells you nothing about whether anyone came back.

Then the avatar, and I mean an actual person

The second decision is who this room is for. Not a segment, not a persona deck with a stock headshot and a fake name. One person, described closely enough that you could predict what annoys them. Someone joins at 2am. They came from a video, they have one specific problem, and they have roughly thirty seconds of patience before the tab closes. What do they see first? Is the answer they need within two clicks, or is it in a pinned message inside a channel they cannot see yet because they have not clicked a reaction on a rules page nobody reads?

A community does not lose people at month three. It loses them in the first two days, quietly, and nobody files a report about it.

Getting the avatar right decides the entire onboarding path. A room built for developers who arrive with an error message needs a fast route to a searchable answer and a visible human. A room built for creators who arrive with something to show needs an obvious place to post it and a reason to expect a response. Build the wrong one and every later decision inherits the mistake. This is also where I push back hardest. Teams often describe the member they wish they had rather than the one who actually joins. The wish version is more advanced, more patient, and more motivated than the real one. Designing for that person is how you end up with a server that only works for the five people who were already going to stick around.

Then one sentence for the server goal

The third decision is the one everything else hangs from. We write the server goal as a single sentence that any person on the team could repeat from memory.

This server exists so that [SPECIFIC PERSON] can [do a specific thing], which gives the business [specific outcome].

It sounds almost too simple until you try to fill it in with a real team in the room. The arguments that surface during that exercise are the arguments that would otherwise surface six months later as a dead channel nobody wants to delete. Once the sentence exists, it becomes the filter. Every proposal after that point gets one question. Does this serve the sentence? A channel someone requested because a competitor has one usually does not. An escalation path from a support thread to a named human usually does. The sentence lets you say no without it becoming a matter of taste, which is the real reason servers bloat. Nobody wants to be the person who rejected a colleague's idea, so everything gets built and nothing gets maintained.

The practical test. If two people on your team write the server goal from memory and the sentences do not match, you do not have a goal. You have a preference, and preferences change every time leadership changes.

Only then, the build

With those three settled, the build becomes mechanical in the best way. Structure, onboarding, roles, automation, moderation, escalation. Each one is a design decision with a clear reference point. Structure means the smallest set of channels that serves the sentence, with names a newcomer understands without a legend. Onboarding is not a welcome message, it is a sequence: a guided entry, a structured introduction, one obvious first action, and contact with a real person early enough to matter. Roles carry permissions and recognition, and they should map to behavior you actually want repeated. Automation takes the repetitive load, meaning role assignment, routine answers, entry guidance, and moderation triggers, while humans keep the conversations that build trust. Moderation and escalation define what happens when something goes wrong at 3am and the person who usually handles it is asleep. None of that is exotic. The reason it works is the order it was decided in.

Scale changes the machine, not the order

I have run rooms at very different sizes, and the order held at every one of them. What changed was how much machinery the room needed underneath it.

Size	What actually carries the community
100	Personal relationships and the founder showing up
1,000	Structured onboarding becomes necessary
10,000	Documentation systems become critical
100,000	Automation and moderation frameworks required
1,000,000+	Full operational infrastructure and specialized teams

At BlueWillow.ai the room went from roughly a thousand members to 1.7 million while I managed it, at the time the second largest Discord in the world, holding around fifteen percent engagement. At that size every unclear rule becomes a thousand tickets and every missing escalation path becomes an incident. At Google Developers as Head Discord Moderator, the constraint was different. The standard was not volume, it was consistency, because a platform community carries the reputation of the platform in every reply. At Sapien.io I led an eighty thousand member developer community where the technical depth of the audience meant weak answers cost more than slow ones. Moonvalley.ai and the others each had their own version of the same tension. Different products, different avatars, different sentences. The sequence never changed.

How to check your own server this week

You do not need a consultant to run the first diagnostic. Open your server and try three things. Write the server goal from memory, then ask two teammates to do the same, and compare the three sentences. Next, create a fresh account and go through your own onboarding at full speed with no shortcuts, watching for the exact moment you would have given up. Then list every channel and mark the ones that had a message today. The channels that fail that test are not neutral. They are telling every new member that this room is emptier than it looks. What you find will usually point back to a decision that was never made, which is the same place the work always starts.

Order is the cheapest advantage in this work. Most rooms are not broken, they were simply built before anyone decided what they were for, and that is fixable in a way that a taste problem never is. If you want the room to carry weight, define the sentence first and let everything else answer to it. *More at *danieljeong.org