How to Build a Discord Bot as a Side Project

To build a Discord bot as a side project that servers actually keep, pick one job for one kind of community, ship it as slash commands first, and design around the limits Discord sets from day one: a small permission list, no privileged intents unless the bot cannot work without them, and an answer to every command within 3 seconds. Most first bots fail the other way round: ten features, Administrator access, and a laptop host that goes to sleep.

Last checked: Nov 9, 2026

For developers with a day job who build on evenings and weekends. Discord rules and numbers below were checked on Discord's official docs on 9 November 2026 and can change. The worked example is made up.

When is a Discord bot the right side project?

A Discord bot is a good side project when the people you want to help already spend time in a Discord server and the job happens inside the conversation. If people have to leave the chat anyway, a small website is simpler.

One test: write the sentence an admin would use to tell members why they added your bot. If you cannot, you do not have the idea yet.

What one job should your Discord bot do?

Bots that stay installed do one thing a specific community repeats every week. Start from a group you know, not a feature list. Shapes that work for a first Discord bot side project:

• Running or cycling club: log a weekly distance with one command and post a Sunday leaderboard.

• Study group: a timer that starts a focus session for everyone in a voice channel and posts who joined.

• Tabletop group: a session scheduler that finds the night most players can make.

• Pub quiz or trivia league: score entry after each round and a season table.

Missing on purpose: moderation suites, music players and all-in-one bots. They are crowded, need heavy permissions, and are hard to run on a few hours a week.

How do you set up the app, the bot user and the token?

Everything starts in the Developer Portal, and Discord's first bot tutorial walks through it:

1. Create a new application in the Developer Portal and give it the name people will see.

2. Open the Bot page. New apps have a bot user enabled by default, which is what appears in a server's member list.

3. Under Token, click Reset Token and copy the token once; Discord will not show it again unless you regenerate it.

4. Put the token in a local .env file that is listed in your .gitignore, and in your host's secret settings for production.

5. Note the application ID and public key. You need the public key for an HTTP endpoint later.

Treat the token like a password for your whole bot. Discord's tutorial calls it highly sensitive and says never to share it or check it into version control. If it lands in a public repo, a screenshot or a pasted log, reset it, update your host and redeploy. Resetting is cheap; cleaning up after someone else drives your bot is not.

Server install or user install: which should you support?

Discord apps can be installed in two contexts, and choosing early saves rework. Per Discord's application docs and tutorial:

• Server (guild) install: must be authorised by a member with the Manage Server permission, and the app is visible to everyone in the server. This is the classic bot.

• User install: visible only to the person who installed it, across their servers and DMs, and limited to commands. Followup messages are also capped at 5 per interaction when the app is installed only to the user and not to the server.

A leaderboard or scheduler needs a server install, because everyone should see the same thing. A personal helper, like a unit converter, can be a user install with no server permissions. Discord's tutorial recommends supporting both by default, but a first project is easier to reason about with one. Pick the context that matches your one job and add the other if people ask.

Which scopes and permissions should your install link ask for?

Ask for the least you need; a long permission list is the fastest way to lose an install.

The default Discord Provided Link on the Installation page is limited to two scopes: applications.commands, which lets you register commands, and bot, which adds the bot user. For a user install you only need applications.commands. With bot, pick only what your one job uses, often Send Messages and Embed Links. A Custom URL can point to an OAuth2 authorize URL with its own scopes and permissions.

Never request Administrator. Discord's permissions reference says it allows all permissions and bypasses channel permission overwrites. A bot that asks for three permissions and explains each looks like a tool. A bot that asks for everything looks like a risk.

Why should slash commands come before reading messages?

Slash commands are the native way to call an app: people type a slash, pick your command and fill in options. They show up in the command picker, and the interaction payload already includes the member who used them, with roles and permissions.

The old way, reading every message for a prefix, needs the Message Content intent, one of three privileged intents:

• Message Content: message text, embeds, attachments, components and polls.

• Server Members: join, leave and update events and full member lists.

• Presence: online status and activity.

Discord's guide on why you might not need a privileged intent says switching text commands to slash commands is the most common way developers drop Message Content, and that slash commands do not require any privileged intents.

What changes as your bot grows?

Two thresholds matter, and they are different:

• App verification at 100 servers. Discord's help article on getting your app verified says verification is required for an app to scale past 100 servers. The team owner verifies their identity through Stripe.

• Privileged intent review at 10,000 users. Since June 10, 2026, per Discord's privileged intent review guide, the review threshold is based on unique users who can see your app across its servers, not on server count. Under 10,000 you toggle intents yourself. Above it you have 90 days from the notification to apply, and approved apps reapply every year.

So a bot in a few large servers can need review before a bot in many small ones. Slash commands from day one mean neither threshold forces a rewrite.

Gateway or HTTP endpoint: how should you host a Discord bot?

Per Discord's interactions overview, interactions arrive one of two mutually exclusive ways: over a Gateway WebSocket connection by default, or as HTTP POST requests if you add an Interactions Endpoint URL.

If your one job is driven by commands, HTTP is often the cheapest way to host a Discord bot, because nothing runs between requests. Discord publishes a tutorial for hosting on Cloudflare Workers, citing the free tier, and notes one catch: Workers cannot fetch non-ephemeral CDN media such as older attachments. Your endpoint must validate the X-Signature-Ed25519 and X-Signature-Timestamp headers on every request and return a 401 when they fail.

What limits will your bot hit first?

The first limit is time. Per Discord's docs on receiving and responding to interactions, you must send an initial response within 3 seconds or the interaction token is invalidated; after that the token stays valid for 15 minutes for followups. If a command calls a slow API, send a deferred response first, which shows a loading state, and edit the reply when done.

The second is rate limits. Discord's rate limit docs say not to hard-code limits: read the response headers, and wait for retry_after on a 429. All bots can make up to 50 requests per second globally, interaction endpoints are not bound by that global limit, and an IP that makes 10,000 invalid requests (401, 403 or 429) in 10 minutes is temporarily blocked. For a small bot the usual cause is a bug retrying in a tight loop.

The third is command registration: up to 100 global slash commands, and 200 command creates per day per server, so do not re-register commands on every boot.

What should your bot store, and do you need a privacy policy?

Store as little as you can: one table of per-server settings keyed by server ID (which channel to post in, which role runs admin commands) plus the data for the one job. Do not keep message text, member lists or anything you can fetch on demand.

Discord's Developer Policy agrees: use API data only for your stated features, never sell it or pass it to ad networks, and do not train AI models on message content without Discord's express permission. It also requires a way for users to report problems, and that you act on reports.

The app settings have Terms of Service and Privacy Policy URL fields, and both are required if you turn on Discord's payments. Even before that, a one-page policy saying what you store, why, and how a server can ask for deletion reassures admins. The SideHunt guide on writing a privacy policy for a side project covers how to do it in one evening.

Which library should you build a Discord bot with?

Use the language you already write at work. Discord says it does not maintain official SDKs and keeps a list of community libraries with valid rate limit handling across C#, Go, Java, JavaScript, Python, Rust and more.

• discord.js is the JavaScript option most tutorials use. The discord js guide covers setup, slash commands, components, databases and sharding.

• discord.py is the Python option. Its documentation describes an async API with rate limit handling and a commands extension; PyPI lists it under the MIT licence for Python 3.8 or newer.

• Raw HTTP: a three-command HTTP bot may only need signature verification and a few API calls.

How do you test without annoying real servers?

Create a free private server for testing; Discord's tutorial says to test in a server not actively used by others. Register guild commands there while you build, because Discord says guild commands update instantly, and switch to global commands for real installs.

Use a second application with its own token for development, so a broken build never answers in a real server. Ask a friend without admin roles to try it; permission bugs only show up for people who are not you.

How do you keep it running cheaply and know when it breaks?

Match hosting to delivery. An HTTP bot can sit on a serverless or edge platform that costs little at low volume. A Gateway bot needs one small always-on process; a sleeping laptop or a plan that spins down when idle drops the connection, and the bot goes quiet without telling anyone.

Add two cheap safety nets: log failed interactions with command name and server ID, and post to a private test channel when the bot restarts or keeps erroring. For a fuller setup around a day job, see the SideHunt guide on monitoring a side project during your day job.

How do you get your bot into servers?

Start with servers where you are already a trusted member. Ask the admin, explain the one job in a sentence, and offer to remove it after two weeks if it is not useful.

Discord's App Directory and App Launcher come next. Per its guide to enabling discovery, your app must be verified, then you opt in to Discovery and fill in your listing; it can take up to 24 hours to appear. Third-party bot lists such as Top.gg let people browse bots by tag and vote; treat them as one more channel and keep the listing honest.

Can you charge for a Discord bot?

Maybe, but check the rules first. Premium Apps let verified apps sell subscriptions and one-time purchases through Discord's checkout. Per the monetization setup guide, the app must be verified and owned by a developer team, the team owner must be at least 18, the app needs slash commands or approved Message Content access plus Terms and Privacy Policy links, and payouts run through Stripe after the first $100. Premium Apps is currently only available to teams based in the United States, the European Union or the United Kingdom.

The Developer Policy adds a rule people miss: where Premium Apps is supported, paid features must also be offered through it, at a price no higher than through other payment options. So an external payment link alone is not a free choice everywhere. For a first side project, ship free, earn installs, and read the current terms when people ask for more.

What abuse should you plan for?

Any bot that repeats user text can be used to ping everyone. Discord recommends the allowed_mentions field when your app responds with user data, so a team name containing a mass mention notifies nobody. Cap how often one user can run a command and let admins limit commands to a role. The Developer Policy also rules out unsolicited DMs, advertising to users and automated messages that fake activity. If people can post content others see, the SideHunt playbook on handling spam and abuse when users can post covers reports, rate limits and takedowns.

A made-up example: Scorlet for a pub quiz league

Invented to show the decisions, not a real product. Ilkka, a backend developer, plays in a six-team pub quiz league that runs in one Discord server. Every Thursday someone types scores into a spreadsheet and posts a blurry screenshot.

• One job: log round scores and post the season table. Nothing else.

• Install: server install only, with Send Messages and Embed Links.

• Delivery: HTTP interactions on an edge worker, because every action is a command.

• Commands: /score, /table, and /season for the organiser role only.

• Data: team names, scores and one channel setting per server. No message content, no member list.

• Slow path: /table renders an image, so Scorlet defers first.

Ilkka tests with a dev application in a private server, then asks the league admin to add the real one. Two other leagues hear about it from players and ask for the link. The next weekend goes on the one thing people asked for: a tie-break rule.

Common Discord bot traps

• Asking for Administrator because a tutorial did.

• Turning on all three privileged intents "just in case".

• Reading every message for a text prefix instead of using slash commands.

• Committing the bot token, or pasting it into a support chat.

• Doing slow work before the first response and missing the 3-second window.

A one-weekend plan

FAQ

Do I need to host a Discord bot 24/7?

Only if it uses the Gateway to react to messages, joins or other events. A command-only bot can use an HTTP interactions endpoint on a serverless or edge host, as long as it answers each interaction within 3 seconds.

Does my Discord bot need verification?

Not at first. As of Nov 9, 2026, verification is required to grow past 100 servers, for App Directory discovery and for monetization. Privileged intents have a separate review above 10,000 unique users.

Can I charge for a Discord bot?

Yes, through Premium Apps if your team is based in the US, EU or UK and your verified app meets Discord's checklist. In those regions, paid features must also be sold through Premium Apps at no higher price than elsewhere.

Which Discord bot library should I start with?

Use the language you already know; both are in Discord's community library list. For a tiny HTTP bot, either language with no full library can work.

Ship the bot one server keeps

Your first Discord bot does not need to be big. It needs to do one job well enough that an admin forgets they installed it. When it is ready for more people, share it with other builders on SideHunt.