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

Start a community build with channels and you get an empty room. I work in a fixed order: understand the business, define the one real person who joins, write a single sentence naming what the server is for, and only then build. The sentence is what lets you say no to everything that does not belong.

The screenshot problem

There is a specific kind of server I get called into. It looks finished. Categories are tidy, the emoji are consistent, there is a rules page and a welcome message and a bot that greets people. It photographs well.

It is also quiet, and nobody on the team can say why.

The cause is nearly always the same. The room was designed as a layout instead of a system, and a layout cannot tell you what belongs in it. That is why I spend the first stretch of any engagement talking about the business and refusing to open the channel list.

Decision one: what the business actually does

Community strategy is downstream of the business model, so I start there.

1. How the money moves. What gets bought, by whom, and what has to be true before someone buys.
2. Where things break. The recurring friction, and which person on the team currently absorbs it.
3. What is being done by hand. Anything repetitive a system should be carrying already.
4. What success looks like in six months. Stated plainly enough that leadership would recognize it.

When a team cannot answer the fourth one, that is not a failure of the meeting, it is the finding. Undefined success defaults to counting members, and member count rises with any campaign while telling you nothing about whether a single person came back.

Decision two: the person, drawn close

Then we define who the room is for, and the standard is high. Not a segment. Not a slide. One person, specific enough that you can guess what would make them close the tab.

Picture them arriving at 2am from a video, carrying one problem and very little patience. What is the first thing they see? How many clicks until they have what they came for? Is there any evidence a human is present, or does the room look automated all the way down?

⚠️ Teams describe the member they wish they had. More motivated, more patient, more technical than the real one. Design for that imaginary person and the server will only work for the few who never needed help in the first place.

The avatar decides onboarding. Someone arriving with an error message needs a fast path to a searchable answer and a visible human. Someone arriving with work to show needs a place to post it and a real chance of a response. Those are two different rooms, and no amount of good channel naming will convert one into the other later.

Decision three: the sentence

Everything after this point hangs from a single line of text.

This server exists so that a specific person can do a specific thing, which gives the business a specific outcome.

Write it, fit it on one line, and make it repeatable from memory. The disagreements that surface while filling in those blanks are the same disagreements that would otherwise appear months later as an abandoned channel nobody has the authority to delete.

After that, the sentence does the hardest work in the whole engagement. It answers requests. Someone wants a channel because a competitor has one, and the sentence says no without anyone having to make it personal. Someone proposes a route from a stuck support thread to a named human, and the sentence says yes immediately. Server bloat is rarely a design failure. It is a governance failure, and a shared sentence is the cheapest governance available.

What gets built, and in what order

Once the three decisions hold, the build stops being a debate.

Automation deserves one clarification, because it gets oversold constantly. It carries load, not relationships. Role assignment, routine answers, entry guidance, and moderation triggers all belong to systems. The conversation that turns a lurker into a regular does not.

The same order at every size

The machinery scales. The sequence does not change.

BlueWillow.ai grew from around a thousand members to 1.7 million while I managed it, at the time the second largest Discord globally, running near fifteen percent engagement. At that size, an unclear rule turns into a thousand tickets and a missing escalation path turns into an incident with an audience. Google Developers, where I served as Head Discord Moderator, demanded something different: consistency, because every reply carries the platform's reputation. At Sapien.io I led community for more than eighty thousand technical members, where a shallow answer costs more than a slow one. Moonvalley.ai brought its own shape again.

Four rooms, four avatars, four sentences, one order.

What changes with scale is how much infrastructure sits under the room. At a hundred members, relationships carry it. At a thousand, onboarding has to be designed. At ten thousand, documentation becomes the backbone. At a hundred thousand, automation and moderation frameworks are not optional. Past a million, you are running an operation with specialized teams, and the quality of the early decisions is the only reason it stays coherent.

Try the diagnostic yourself

Three checks, no consultant required.

Ask two teammates to write the server goal from memory and compare all three sentences. Then join your own server on a fresh account and move through onboarding without skipping anything, marking the exact point where a normal person would leave. Finally, list every channel and flag the ones with no message today, because a quiet channel is not neutral. It is evidence, and new members read it faster than they read your rules page.

Most of what you find will trace back to a decision nobody made. That is where the work starts, and it is a far better problem to have than a taste problem.

The rooms that hold up are not the ones with the best layout. They are the ones where somebody decided, early and in writing, what the room was for, and then had the discipline to keep everything else pointed at it. That discipline is buildable.

Start at danieljeong.org