Boty Discord

Our brands' communities live on Discord, not on a website. That is where a new client lands, where they open a ticket, where they wait for the role that grants access to the right channels. At a few hundred members, handling tickets, welcomes and roles by hand simply stops holding together - someone has to be there, watching and clicking, and that does not scale with the number of people.

Instead of writing one universal bot to do everything, we built one core and a set of modules from which each bot is assembled separately. Four servers, four roles, four configurations - but one place where the logic lives. This case study is about why that split paid off more than a monolith that would have been convenient at the start.

It is tempting to write one bot that does all the work across every server. The trouble is that each server has slightly different needs: a different team to ping on a ticket, a different join path for a new member, different roles and a different verification threshold. A universal bot meant to handle them all slowly turns into a christmas tree of flags nobody wants to touch, because it is unclear what else depends on any of them.

The second trap is shared state. One process serving four servers at once is a single point of failure - a bug in the ticket logic can take down welcomes on an entirely different server. And the more unused code a server carries, the harder it is to safely change anything in it.

We went the other way: one core with modules, which in the Discord ecosystem are called cogs, and each bot is a set of enabled cogs. The ticket server takes the ticket cog; a server that does not need it simply does not turn it on.

In practice the ecosystem is four separate bots, each doing one thing well. The ticket bot opens ticket threads and pings the right team so a report does not get stuck in a void. The welcome bot walks a new member through their first steps. The verify bot confirms an email address on join. The roles bot keeps role hygiene and assigns them automatically.

This split is not cosmetic. Each bot has its own permission scope and its own state, so one failing does not drag down the rest, and a change in one does not require thinking about the other three. Only the core is shared - how a cog attaches to a bot, how it reads config and how it talks to the API.

A cog is a self-contained unit: its own commands, its own listeners, its own state. You attach it to the bot in one line and detach it the same way. There is no global tangle - the ticket cog knows nothing about the roles cog and does not need to. Below is a slice of verification: a new member gets a pending role and a prompt to confirm their address before they see the rest of the server.

Names like on_member_join or add_roles are dictated by the Discord API and stay as they are - the rest of the identifiers follow our own convention. This is the boundary where you follow the library, not your own style, and the only place where two naming conventions mix.

The biggest gain is not visible on the server but in how these bots are maintained. A fix in the ticket logic lands in one place and reaches everywhere that cog is enabled - you do not rewrite it four times and forget one server. No server carries code it does not use, so its configuration is exactly as complex as its real needs.

Adding a fifth server does not mean writing a fifth bot from scratch. You assemble it from what already exists: take the cogs that fit, set the configuration, and that is it. That is the difference between four separate projects and one ecosystem that grows by adding modules, not by multiplying code.