Start with the job, not the feature list
Before choosing features, write down what your moderators and community managers spend their time on. In most servers the answer is the same handful of jobs: welcoming people and checking they are real, handing out roles, answering the same questions, dealing with rule breakers and keeping a record of it, and moving support requests somewhere they will not be lost.
Each of those is a good first feature because it saves time from day one, it is easy to measure, and nobody has to be persuaded to use it. A points system or a mini-game, by contrast, only works if members care, and you cannot know that until the basics are running.
What to build first
- 01
Onboarding and verification
A welcome flow that asks new members to accept the rules, optionally links an account elsewhere, and only then opens the server. It stops most spam accounts at the door and gives every member the same first experience.
- 02
Self-service roles
Buttons or a menu for members to choose their region, language, interests or notification preferences. It removes a steady stream of requests from moderators and keeps channels relevant.
- 03
Moderation actions with a log
Warn, time out, kick and ban through commands that record who did what, when and why, in a private channel and in a database. Consistent records are what make moderation fair, and what let a team hand over between shifts.
- 04
Answers to common questions
A small set of slash commands, or a searchable FAQ, that posts the official answer. The text lives in a dashboard so staff can change it without a developer.
- 05
Support tickets
A button that opens a private thread or channel between a member and the support team, with the transcript saved when it closes. It is the feature community managers ask for most once they have it.
Five features is a complete first release for most communities. It can be built, tested and handed over quickly, and it produces the usage data you need to decide what to build next.
How Discord bots work, in brief
Modern Discord bots are built around application commands. There are three kinds: slash commands that appear when a member types a forward slash, and user and message commands that appear when someone right-clicks or taps on a member or a message. An app can register up to 100 global slash commands, plus 15 user and 15 message commands [1]. That is plenty; a bot that needs more is usually several bots in one.
When a member uses a command or presses a button, Discord sends the bot an interaction, and the bot must send an initial response within 3 seconds [2]. Anything slower, such as calling another system or an AI model, has to acknowledge first and follow up later, and the interaction token used to follow up is valid for 15 minutes [2]. Designing for that from the start avoids the commonest first-version bug: commands that work in testing and fail when the server is busy.
To react to events that are not commands, such as a member joining, a bot connects to Discord's gateway and declares intents: the categories of events it wants to receive [3]. And every bot works within rate limits. Discord's documentation states that bots can make up to 50 requests per second to its API, and that an address making too many invalid requests, currently 10,000 per 10 minutes, is temporarily restricted [4]. A bot that mass-assigns roles or posts to every channel at once has to queue its work.
Ask for as little access as you can
Some intents are privileged because of the data they expose: server members, presence, and message content [3]. Without the message content intent, a bot sees empty content in most messages it did not send or was not mentioned in [3]. Discord's documentation also says that once an app has more than 10,000 unique users who can see it across its servers, it needs review for continued access to privileged intents, and that verified apps, which an app needs to be once it is in 100 or more servers, must have each privileged intent approved [3].
The practical lesson is to design features that do not need privileged access where you can. Slash commands, buttons and menus deliver their own input to the bot, so a FAQ, a ticket system or self-service roles do not need to read every message. Keyword-based automoderation does, and Discord's own AutoMod may cover it without a custom bot at all.
- Ask for the server members intent only if you need join and leave events, for onboarding or member counts.
- Avoid the message content intent unless a feature genuinely reads free text, and write down why for the review.
- Give the bot's role only the permissions its features use. A bot with administrator rights is a single point of failure for the whole server.
What to build later, or not at all
| Feature | When it makes sense | Watch for |
|---|---|---|
| Levels and points | Once the basics run and you want to reward helpful members, not just noisy ones | Rewards for message count invite spam. Reward answers, events and contributions instead |
| An economy or shop | When points can be spent on something members value, such as roles or event access | Anything with real-world value raises questions for your advisers |
| AI chat or answers | When your FAQ is large and well kept, so the bot can answer from it with sources | It needs evaluation, limits and a way to hand over to a person |
| Linked accounts | When members also use your website, app or game | Sign-in through Discord's OAuth, and a clear privacy notice |
| Music and media | Rarely for a business community | Licensing for the content, and platform rules |
| Cross-posting to Telegram or other platforms | When your community really is split across them | Moderation decisions need to travel with the messages |
Two Discord projects, priced from our rate card
The worked examples below show the range from our rate card today, with the payment schedule and the monthly running cost. The first is the five-feature first release above. The second adds a web dashboard where staff manage the bot, members link their accounts and the team sees how the community is doing.
Worked example, priced now
A first-release community bot
Onboarding and verification, self-service roles, logged moderation actions, FAQ commands and support tickets, with a small settings page for staff.
- Build
- ≈ US$11,900 to US$18,200, delivered within 4 weeksCAD 17,000 to 25,900
Prices in your currency are estimates from today's Bank of Canada rate. All invoicing is in CAD or USD.
How it is paid
- Deposit 30%
- CAD 5,100 to 7,770
- Commands agreed 15%
- CAD 2,550 to 3,885
- Working in a test server 30%
- CAD 5,100 to 7,770
- Launch 15%
- CAD 2,550 to 3,885
- Holdback, 30 days after launch (10%)
- CAD 1,700 to 2,590
Running it
- Hosting
- ≈ US$176 a monthCAD 250 a month
- Support
- ≈ US$1,000 a monthCAD 1,425 a month
Worked example, priced now
A community bot with a web dashboard
The same bot plus a web dashboard with Discord sign-in, live moderation and ticket views, member analytics, integrations with the rest of your stack and a support plan.
- Build
- ≈ US$50,500 to US$77,200, delivered within 16 weeksCAD 71,900 to 109,900
Prices in your currency are estimates from today's Bank of Canada rate. All invoicing is in CAD or USD.
How it is paid
- Deposit 30%
- CAD 21,570 to 32,970
- Discovery 5%
- CAD 3,595 to 5,495
- Commands agreed 3.5%
- CAD 2,516.50 to 3,846.50
- Design approved 5%
- CAD 3,595 to 5,495
- Core features 15.2%
- CAD 10,928.80 to 16,704.80
- Full build 10.1%
- CAD 7,261.90 to 11,099.90
- Working in a test server 7.1%
- CAD 5,104.90 to 7,802.90
- Testing and fixes 5%
- CAD 3,595 to 5,495
- Launch 9.1%
- CAD 6,542.90 to 10,000.90
- Holdback, 30 days after launch (10%)
- CAD 7,190 to 10,990
Running it
- Hosting
- ≈ US$176 a monthCAD 250 a month
- Support
- ≈ US$2,500 a monthCAD 3,565 a month
Running a bot after launch
A bot that listens to the gateway is a program that has to stay connected all day, every day. Plan for where it runs, how it restarts after a crash, and how you will know it is down before your members tell you.
- Host it on a server or container platform with automatic restarts and health checks, not on someone's computer.
- Keep its data (moderation logs, tickets, settings) in a proper database with backups, not in files beside the code.
- Log every command and every failure, so a moderator's question about what happened can be answered.
- Keep the bot's token in a secrets store, rotate it if it ever leaks, and never paste it into a chat.
- Watch Discord's developer changelog. Platform changes arrive with notice, and a bot that nobody maintains stops working quietly.
Knowing whether it worked
Decide what success looks like before the bot goes live, so the next feature is chosen on evidence rather than on whoever asks loudest. The bot can count most of it for you.
- Onboarding: how many people join, how many complete verification, and how many leave in their first week.
- Moderation: actions per week, repeat offenders, and how long a report waits before someone acts on it.
- Support: tickets opened, time to first reply, time to close, and which questions keep coming back.
- FAQ commands: which answers are used most, and which questions still reach a person. Those are the next answers to write.
Check what Discord already does before paying for it. Community servers have built-in onboarding questions and AutoMod, and for a small server they may be enough. A custom bot should do what those cannot: your rules, your records, and links to your own systems.
A checklist for your brief
- 01
Name the jobs
List what moderators and managers do by hand each week, and how long it takes them.
- 02
Pick the first five
Choose the features that save the most time and need the least access.
- 03
Decide who edits what
FAQ text, role menus, welcome messages and log channels should be editable by staff without a developer.
- 04
Write down the access you need
Intents and permissions, and why each is needed. It speeds up review and keeps the bot safe.
- 05
Plan the running
Hosting, monitoring, backups and who to call. A bot is a service, not a one-off file.