An Open Invitation to Founders, Heads of Marketing, and Heads of Community Who Need a Discord Built
If a community build is sitting on your roadmap without an owner who has done it at scale, this is what hiring me looks like and how the work actually runs.
If you are a founder, a head of marketing, or a head of community and a Discord build sits on your roadmap without an owner who has done it at scale, this is an invitation to hand it to someone who has. Full builds, rebuilds, and audits, ending in operating documents your team keeps.
Who this is written for
Three people usually find their way to a page like this. The first is a founder. Community keeps coming up in leadership discussions, usually attached to retention or support load, and there is broad agreement that it matters. Nobody in the room has built one before, so the plan stalls at the point where someone has to own it. The second is a head of marketing. A server already exists because launching one felt cheap and obvious. It sits in the sidebar with a member count that goes up and a conversation that does not. Community landed on the marketing roadmap next to campaigns, and campaign tactics are not fixing it. The third is a head of community. This person knows precisely what the server needs. Better routing at entry, a support path that does not run through direct messages, roles that map to what people actually paid for, automation that carries the repetitive load. They also have a full week of member facing work and no engineering hours to build any of it. Brands, agencies, and paid communities all show up in one of those three shapes. The problem is the same underneath. Someone has to design the infrastructure, and it is a specialist job.
What I do
I build Discord as revenue infrastructure. Not social media management, not moderation staffing, not a bot recommendation list. The work is architecture and operations for a place your members return to.
| Layer | What gets built |
|---|---|
| Architecture | Category and channel structure sized to your team, permission model, role hierarchy |
| Entry | Onboarding sequence, door questions, routing by member type, first action design |
| Support | Ticketing, escalation path, ownership per channel, response windows |
| Automation | Role assignment, repeat answers, moderation triggers, alerts on high value activity |
| Operations | Playbooks, moderator guidelines, review cadence, the documents your team runs it with |
That last row is the one that decides whether the build survives. A server you cannot operate without me is a failed build. Every engagement ends with written systems your team owns.
The three ways this usually starts
| FULL BUILD | empty or near empty server, designed and built end to end |
| REBUILD | a server that grew without a plan, restructured without losing members |
| AUDIT | a working server, reviewed layer by layer, with a fix order and a written plan |
Most people arrive thinking they need the first one and actually need the second or third. That gets sorted in the first conversation, before anyone commits to scope.
How an engagement runs
The sequence rarely changes.
- Scope the outcome. One conversation about what the server is supposed to do for the business. Retention, support deflection, upgrade path, developer relations, member accountability. Every structural decision after this depends on that answer
- Audit what exists. Current structure, permissions, integrations, and what members experience on arrival. Written up plainly, including the parts that already work
- Design before building. Architecture, entry flow, permission model, and support paths documented and approved before a single channel changes
- Build and instrument. Structure, roles, automation, and moderation frameworks implemented, with the two or three metrics you will actually report wired in
- Hand over. Operating documents, moderator guidelines, and a review cadence, so the system belongs to your team No step gets skipped, including the boring ones. The skipped design step is why most servers need a rebuild eighteen months in.
The build is the easy half. Designing what to build, and writing it down so other people can run it, is the work you are hiring for.
Where I come from
Credentials matter here only because they tell you what I have already survived.
I managed a Discord from roughly a thousand members through 1.7 million, at the time the second largest on the platform, at around fifteen percent engagement. I served as head Discord moderator for Google Developers. I led community for an eighty thousand plus developer audience in the Web3 and AI space. I am Top Rated Plus on Upwork, and I run a one person practice supported by heavy agentic infrastructure, which is why the output looks like a small team without the agency overhead attached to your invoice.
The technical side is YAGPDB, Discohook, AutoMod, Sapphire, and the rest of the standard operating stack, plus production pipelines for reusable brand assets. That part is table stakes. The reason to hire me is the strategic layer sitting above it.
Who I am not the right fit for
Worth stating plainly, because it saves us both time.
- Anyone who wants a full server built over a weekend. Design takes longer than assembly, and the design is the deliverable
- Anyone expecting community to replace acquisition. A server holds an audience you already have. It does not find you a new one
- Anyone who wants a list of bots to install. Tools without an operating model produce the quiet server you are trying to escape
- Anyone who wants a moderator on retainer rather than infrastructure. That is a staffing need, and it is a different hire If you read that list and still want to talk, we will probably work well together.
What the first conversation looks like
No deck, no discovery marathon. One conversation, usually under an hour, covering what the community is for, who is in it, what your team can realistically staff, and what you want to be true six months from now. You leave that conversation with a direction whether or not you hire me, because the diagnosis is the part I cannot fake and would rather give away. If your community is on the roadmap this quarter, or if it launched and went quiet and nobody wants to say so out loud, that is the right moment to reach out. Servers get harder to restructure as they fill, and every month of drift adds work to the rebuild. The seat is open. Bring the problem.
*Community infrastructure is a design discipline, and the teams that treat it that way end up with rooms people return to. If yours deserves that attention, start the conversation at *danieljeong.org