Discord Community Setup Cost vs Monthly Retainer: What You Are Actually Buying

A setup fee should buy artifacts you keep: architecture, onboarding copy, exported automations, an escalation ladder, an answer library, a reporting definition, and a handover document. A retainer should buy named coverage hours on top of those. If the contract ends tomorrow and you own only a server, the split was never made.

---

Setup cost and retainer are two different purchases

A setup cost buys a build. A monthly retainer buys a run. They are not competing prices for the same service, and comparing them as though they were is what produces the eight month contract that leaves nothing behind. A build produces objects. Documents, configurations, written decisions, exports. You keep them when the relationship ends, and their value does not depend on anybody's continued attention. A run produces coverage. Somebody is awake, somebody answers, somebody decides whether that member gets removed. Coverage is real work and it is worth paying for, but it evaporates the moment payment stops, which is the correct behaviour for a service. Budget for both. Just never let one invoice line carry both, because the line that carries both always resolves into hours.

The ownership test

One question settles most of this, and it takes ten minutes to answer honestly.

If the contract ended tomorrow morning, what would you still own?

Write the actual list. Not what was promised at kickoff, and not what was discussed on calls. What exists as a file, a document, or a configuration inside an account with your company's name on it. The common answer is a Discord server, a handful of bots configured by somebody who is leaving, and a general sense that things were going well. That is not a build. That is a rented operator whose knowledge lived in their head for the entire engagement.

Seven artifacts that make a build real

This is the roster worth writing into scope, with a delivery date attached to each line.

• Channel and role architecture, with the reasoning written down. The map matters less than the rationale. A future hire needs to know why members-only sits behind a role rather than behind a password, or they will undo it in month two.
• The onboarding sequence, copy included. Every message a new arrival sees in their first three weeks, written out, in a document you can edit without a contractor.
• Automation configurations, documented and exported, inside your accounts. Ownership is the operative word. Configurations that live in a vendor's personal workspace are not yours no matter how the invoice is worded.
• An escalation ladder. Who handles a rude member, who handles a scam, who handles a public complaint about the company, and at which point a name from your side gets involved.
• An answer library. The recurring questions and their current answers, in a place your team can update, so the knowledge stops depending on one person's presence.
• A reporting definition. What gets counted, how it is counted, and which number goes into the monthly business review. Without this, the metric quietly changes meaning whenever the person producing it changes.
• A handover document. Who does what, on which day, with what access. This is the one most often skipped and the only one that makes the other six usable. The first six describe the room. The seventh describes the job, and a build without it hands you a well designed server that nobody knows how to operate.

What hours are legitimately for

None of the above argues against retainers. Some of the most valuable community work cannot be delivered as a document. Coverage is the clearest case. Somebody has to be present during the hours your members are awake, and presence cannot be automated into an artifact. Judgment is the second case. The decision about whether a long-standing member gets a warning or a removal is contextual, and no policy document resolves every instance. Relationship work is the third. The person who knows which member is quietly influential is holding something that only accumulates with time in the room. Buy those hours deliberately, with the coverage window written down. Monday to Friday, 9am to 6pm in two time zones, first reply inside 30 minutes is a retainer you can evaluate. "Ongoing community management" is not.

How to split the money

Structure it in two contracts, or in one contract with two clearly separated sections. The build is fixed scope and fixed price, with the seven artifacts named, dates attached, and a final payment released on acceptance rather than on the calendar. The run is monthly, with coverage hours, response time expectations, and a defined monthly report. The sequencing matters as much as the split. A run that begins before the build is delivered will absorb the build, every time, because live rooms generate urgent work and urgent work always beats documentation. Deliver the artifacts first, then start the coverage clock.

Read the proposal for nouns

A proposal that lists activities has not defined a deliverable. Scan the scope section and mark every line that names a thing you will hold afterwards. Community management, engagement, moderation, and growth are all activities. Architecture document, onboarding copy, escalation ladder, and handover doc are things. Three more clauses worth checking before signature. Access ownership: accounts, bot configurations, and exports registered to your company from day one. Handover: a defined package delivered inside a set number of days after notice, whichever side gives it. Update rights: your team can edit the documents without the vendor, which sounds obvious and is frequently not the case.

The acceptance test

One sentence ends most disputes about whether a build was delivered. Could somebody you hire next month run this room from these documents for two weeks without calling the person who left? Run it as an actual test rather than a rhetorical one. Hand the package to a colleague who was not involved and ask them to describe the first three things they would do on a Monday morning. Their hesitations are your gaps, and finding them before the final payment is the entire point of holding it.

When a pure retainer is the right answer

There is a version of this where hours are all you need, and it is worth saying plainly. If the room already has its architecture, its onboarding, and its documentation, then what you are missing is a person. Buy the person. Paying for another build on top of a working one is the mirror image of the mistake described above. The same is true below a certain size. A community of a hundred members run by a founder who enjoys running it does not need a documented escalation ladder. Documentation earns its keep at the point where more than one person has to make the same decision the same way.

Where this sits in the larger system

Contract structure is one layer, and it is the layer that determines whether every other layer survives a personnel change. The system it protects is the operational build itself: role and channel architecture designed for the size you are heading toward, an onboarding sequence that runs past day one, support routing with a written escalation path, moderation coverage across the hours your members are awake, an engagement rhythm owned week to week, and reporting that connects the room to retention and revenue. Every one of those can be built well and lost anyway, if the contract that produced them never required them to be written down. Open your current agreement and mark the lines that name a thing. If there are none, the next renewal is your opportunity to fix it.

Good community work is visible in the room and durable in the file cabinet. Contracts decide which of the two you get to keep. More at danieljeong.org.