An AI Discord bot can mean two different things. One is a shared bot such as MEE6, Carl-bot or Dyno: the same bot that thousands of servers invite, configured from a dashboard, sometimes with AI chat features sold on top. The other is a custom bot written for one server, which runs that community's own rules and answers from its own documentation. Most servers should start with the first. Some outgrow it.

I built Iryna, the custom AI Discord bot for the official Irys community, as a solo developer, and kept improving it for 5 to 6 months as the server grew past 150K users. This article is what that build taught me: when a custom bot is worth it, what the AI part should and should not do, the parts that are harder than they look and what to ask before you hire someone to build one.

I build custom bots for clients, so I lean toward building. That is my bias, so weigh the advice with it in mind.

01

The short answer

Use a shared bot when standard moderation, welcome messages, leveling and tickets cover what your server needs. Setup takes minutes, and someone else handles hosting and Discord API changes.

Consider a custom AI Discord bot when you are stacking several bots that do not share data, when your moderation rules have to fit your community's own spam patterns and vocabulary, or when you want an assistant that answers from your own documentation and stays in the channels you choose.

02

Shared bot or custom bot: what you actually trade

The choice is less about features than about who owns the rules, the data and the maintenance:

  • Setup: a shared bot is configured in minutes. A custom bot needs a build before it does anything, even when the first version is small.
  • Cost model: a shared bot is usually a monthly subscription, often per feature tier. A custom bot is a build plus hosting plus someone who maintains it.
  • Rules: a shared bot gives you its settings. A custom bot can encode exactly how your community moderates, rewards and onboards people.
  • Data: several shared bots mean several dashboards and several partial views of the same members. One custom bot keeps messages, points and activity in one database you control.
  • Maintenance: with a shared bot the vendor follows Discord's API changes. With a custom bot, that is your developer's job, so ask who does it before you start.

03

Signs your server has outgrown shared bots

Before Iryna, the Irys team combined many different bots to handle moderation, onboarding, games, banned words and other community operations. That pattern is the most common sign. Others usually come with it:

  • Several bots overlap, each with its own roles, permissions and dashboard, and nobody is sure which one acted.
  • Community stats are split across tools, so you cannot see messages, points and activity for the same member in one place.
  • Word filters and spam rules either miss the spam your server actually gets or catch normal members.
  • The same technical questions come up every day, and the answers already exist in your documentation.
  • You want features tied to your own community, such as games, points or onboarding steps, that no shared bot sells.

Iryna replaced that fragmented setup with one bot built around how the Irys community runs: moderation commands, anti-spam protections, onboarding, games and gamification, activity tracking, and AI features.

Read the Iryna case study. The custom AI Discord bot I built solo for the 150K+ member Irys community: scope, stack, constraints and results.

04

What the AI part should do, and what it should not

In Iryna, the AI features were bounded jobs: a RAG assistant that answers developer questions from the project's documentation, and conversational interactions limited to specific channels. Moderation was built from commands, regex word rules and anti-spam protections.

That split is the one I would recommend for most community bots. Retrieval keeps answers tied to your documentation instead of the model's general knowledge. A channel limit keeps the bot from replying where nobody asked it to. Rules make moderation predictable and testable: a member can be told exactly which rule they hit, and a moderator can change that rule without retraining or re-prompting anything.

Letting a model decide on its own to delete messages or punish members is the step I would hold back. If you want AI help with moderation, have it flag messages for a human moderator rather than act.

Read where rules should replace the model. Which steps of an AI workflow need fixed, testable rules, and where a model can safely do the work.

05

The hard parts a demo does not show

A bot that answers well in a test channel is the easy part. The first three below are the constraints I worked through on Iryna; the fourth applies to any bot that answers from documentation:

  • Regex moderation rules have subtle edge cases. A banned-word rule that is too loose misses variants, and one that is too strict catches ordinary words that contain it.
  • Anti-spam has to stay effective without hurting normal usage. The thresholds that stop a raid can also slow down a busy announcement thread.
  • Volume changes the engineering. A bot that works for a few hundred members needs to scale reliably once a large community interacts with it all day.
  • Answers have to stay grounded as the documentation changes, and the assistant needs a clear way to say it does not know instead of guessing.

None of these are solved once. On Iryna, command tuning continued for months after launch, alongside new features.

Read how silent failures hide in AI workflows. Why an automated system can run green and still produce wrong output, and the checks that make the next failure loud.

06

What a custom build looks like in practice

Iryna took one week to set up, then evolved for 5 to 6 months through feature additions and command tuning as the community grew. The stack was Python, Supabase for the data and a VPS for hosting. Expect the same shape: a small first version quickly, then steady tuning based on how members actually use it.

For the first version, I would agree on these with whoever builds it:

  • The one or two jobs it must do on day one, usually moderation and onboarding, with the AI features added once those are stable.
  • The data it keeps, such as messages counted, points and usage stats, and where that data lives.
  • The channels where AI replies are allowed, and what the assistant says when your documentation has no answer.
  • How a moderation rule is tested against real messages before it is switched on.
  • Who changes commands and rules after launch, and how fast.

07

Questions to ask before hiring a Discord bot developer

These separate a bot that survives a large server from a demo. I would ask them of anyone, including me:

  • Can you show a bot running in a live server, with its scope and the size of the community it serves?
  • Who hosts the bot, and who owns the bot token, the code and the community data?
  • How will you test moderation and anti-spam rules so normal members are not caught?
  • Where do the AI answers come from, and what happens when the documentation does not cover a question?
  • Who tunes commands and rules after launch, and how is a change made?

Read: AI automation freelancer or agency?. When one builder fits, when a team fits, and when to train someone in house instead.

08

Where I fit

I take custom Discord bot projects directly when the scope is one bot with a clear owner on the community side, such as a community or marketing lead. Iryna is the reference: built solo, under the direction of the Irys CMO, for a community that grew past 150K users.

If you are deciding whether your server needs a custom bot, describe the bots you run today, what they miss and the questions your moderators answer every day. That is usually enough to tell whether a shared bot with better settings would do.

See how I take freelance AI agent and bot projects. What I build, how engagements work, and how to choose an AI agent developer.