Inside a Discord Build: From Discovery Call to Live Server, Phase by Phase

Hiring anyone to build community infrastructure should not feel like a black box. This is the process we run, what happens in each phase, and what you should expect to receive — written so you can hold any agency to the same standard, including us.

Phase 1: Discovery

A free call in which we map goals, audience and existing setup. The questions that matter are narrower than they sound: what is this community for, what should happen without a human, and what does success look like in six months? Vague answers here produce vague architecture later, so we push until they are concrete.

You get an honest assessment, including the case against hiring us. If a small structured setup covers your need, we say so. Selling a custom bot to a community of eighty people is easy and produces a client who regrets it.

Phase 2: Strategy

Discovery becomes an architecture plan: category and channel map, role model separating access from identity from capability, permission matrix, moderation concept, and — for larger builds — the automation and bot logic with its escalation boundaries.

This is the phase where the decisions that are expensive to reverse are made, which is why it is written down and approved before anything is built. Reordering a channel list after launch costs an afternoon. Changing a permission model after two thousand members have roles costs considerably more.

Phase 3: Build

Structure, permissions, branding, onboarding flow and bot configuration are implemented and tested on a staging server rather than in front of your members. Custom bots are developed against the approved specification: slash commands, ticket panels, integrations, and whatever state the personalisation requires.

Permissions are validated with test accounts that hold exactly one role each, because the settings panel shows intent and test accounts show behaviour. This is also where AutoMod rules and verification level are set, and where the logging that makes later moderation defensible is put in place.

Phase 4: Launch

We migrate or open the server, walk your team through every system, and hand over written documentation: role map, permission matrix, bot command reference and a moderation runbook covering what a warning is, when it escalates and who reviews appeals.

The runbook is the part most handovers skip and the part that determines whether your moderation stays consistent when the person who set it up is unavailable. You own everything: the server, the bot code, the documentation.

Phase 5: Optimisation

A support period follows launch, in which configurations are adjusted against real member behaviour rather than assumptions. The first four weeks always surface something the plan did not anticipate — a question channel that becomes a support queue, an onboarding branch nobody picks, a filter that is too aggressive.

Ongoing maintenance, moderation and hosting are available as optional monthly add-ons. They are optional on purpose: a build that only works while you keep paying us is not a handover, it is a dependency.

Timelines and what moves them

A structured setup typically takes five to ten working days, a larger build with ticketing and moderation systems seven to twelve, and custom bot projects are scoped individually. The variable is almost never our implementation speed. It is how quickly decisions come back in phase two.

One caveat worth stating: if you plan to apply for Discord Server Discovery, factor in its eight-week minimum server age and its activity requirements. That gate is on Discord's clock, not ours, and it is worth knowing before you plan a launch campaign around it.

What we need from you

Three things determine the timeline, and all of them are on your side. Decisions in phase two, returned within a few days rather than a few weeks. Brand assets, if the server should look like your brand — logo, colours, and any tone rules that apply. And access, meaning administrator rights on the target server or a clear statement that we are building on a fresh one.

What we do not need is a finished channel list. Arriving with a fixed structure is common and usually counterproductive: the structure should follow from the goals we establish in discovery, and a pre-built list tends to encode assumptions nobody has tested.

Why we build on staging

Configuration work in a live server is visible to members while it is half-finished. Channels appear and disappear, permissions flicker, and a bot posts test messages into a room where people are talking. That is avoidable, so we avoid it: the build happens on a separate server and moves across once it is complete and tested.

The exception is a migration of an existing community, where the history has to stay in place. There the sequence changes: we prepare everything that can be prepared in advance, agree a window with you, and make the visible changes in one pass rather than over several days.

What the documentation actually contains

A role map naming every role, what it grants and which category it opens. A permission matrix by category, so a future admin can see the model rather than reverse-engineering it from twelve settings panels. A command reference covering every bot function, its parameters and who may use it.

And a moderation runbook: what counts as a warning, when it escalates, who reviews appeals, what the raid response is, and where decisions get logged. That last document is the one that keeps enforcement consistent across shifts and across staff changes, and it is the one most handovers leave out.

Scope, changes and how we price them

The plan approved at the end of phase two is the scope. Changes after that are normal and we would rather have them than a system that matches an outdated plan, but they are quoted before they are built rather than absorbed silently and invoiced later.

Small adjustments during the build are simply part of the build. A new subsystem — a second bot feature, a ticketing flow that was not in the plan — is a scoped addition with its own estimate. The rule we apply is that you should never be surprised by a number.

What usually needs a second pass

After four weeks of real use, the same three things come up across nearly every build. An onboarding branch that nobody chooses, which means the option was written from our assumption rather than your audience. A channel that was meant for discussion and has become a support queue, which usually wants to be a forum with tags.

And an AutoMod rule that is slightly too aggressive, catching a term your community uses legitimately. None of these are failures of the plan; they are the things that can only be learned from members actually using the server, which is exactly why the support period exists rather than the build simply ending at launch.