I have built Discord bots that handle ticket systems, escrow payments, AI moderation, grinder economies, and live tournament brackets across servers with 2,000+ members. The most complex ones took weeks. But a production-quality bot for a focused use case can go from idea to deployed in 48 hours if you know the process. Here is that process, exactly as I run it.
Hour 0 to 4: Planning That Prevents Rewrites
Most Discord bot projects fail not because of bad code but because of bad planning. The developer starts writing slash commands on day one, discovers the architecture does not support what the client actually needed on day five, and rewrites everything from scratch. Forty-eight hours does not survive a rewrite. So planning is not optional.
The questions I answer before writing a single line:
- What is the one core problem this bot solves? Everything else is a feature. One problem first.
- Which Discord events does the bot need to listen to? Message, reaction, member join, voice state change, slash command?
- Does any state need to persist across restarts? If yes, what is the data model?
- Will this run on one server or multiple? Multi-server from day one changes the database design significantly.
- Are there any rate-limited operations? Discord API has rate limits. Plan around them, not into them.
This planning session takes about two hours and produces a one-page spec: the commands list, the data model sketch, and the deployment target. That is the contract for the 48-hour build.
The Stack That Ships in 48 Hours
For a production Discord bot in 2026, the stack I reach for every time:
- discord.js v14 with slash commands registered via the REST API. No legacy message commands. Slash commands have autocomplete, input validation, and proper permissions built in.
- Node.js with TypeScript. TypeScript catches the class of Discord.js type errors that otherwise surface only in production at 2am.
- Prisma with SQLite for simple single-server bots, or PostgreSQL for multi-server deployments. Prisma's migration system means schema changes are tracked and reproducible.
- Railway or Fly.io for deployment. Both support persistent Node.js processes, environment variables, and free tiers that handle bots comfortably up to a few thousand members.
- Pino for logging. Structured JSON logs mean you can grep errors in production without adding debug lines after the fact.
Hour 4 to 28: Building
The build phase follows a strict order that prevents the most common failure modes:
1. Bootstrap with the command handler first. Get one slash command responding before building anything else. The pattern: register commands via REST, set up the interactionCreate event listener, dispatch to command modules by name. Once this skeleton works, every subsequent command is just a new module file. This modular approach means the bot stays maintainable past command 20.
2. Database schema before business logic. Define the Prisma schema and run the first migration before writing any command that touches data. Trying to evolve the schema while simultaneously writing the queries that depend on it creates a moving-target problem that kills momentum.
3. Error handling as a first-class feature. Every command handler wraps its logic in a try/catch that sends a user-facing error message and logs the full stack trace. A bot that silently fails is worse than a bot that has a bug, because silence makes debugging impossible. Users need to know something went wrong. You need to know why.
4. Build the happy path, then the edge cases. Get the core flow working end-to-end first. Then add validation for invalid inputs, rate limit handling, permission checks, and the "what if the database is down" path. Edge cases before happy paths is how you end up with perfectly validated empty software.
Hour 28 to 40: Testing and Monitoring
A Discord bot in production needs two things before launch: a real test on a private server with actual Discord interactions (not just unit tests, because Discord.js event behavior is not fully captured in mocks), and an uptime monitor.
For uptime monitoring, I use Better Uptime or UptimeRobot with a simple health check endpoint added to the bot process. The bot runs an Express server on a separate port that responds to GET /health with a 200. The monitor pings that endpoint every 60 seconds. If the bot crashes, you get a text message before any user does.
The full architecture for larger bots, including the multi-server patterns and AI moderation layer, is in the Discord bot architecture post.
Hour 40 to 48: Deployment and Handoff
Deploy to Railway or Fly.io with environment variables for the bot token, client ID, and database URL. Set up automatic restarts on crash. Enable persistent storage for SQLite or provision a managed PostgreSQL instance for multi-server deployments.
The handoff document covers three things: how to add or remove the bot from a server, how to update slash command definitions when features change, and how to read the logs when something breaks. This document takes one hour to write and saves ten hours of future support calls.
What This Costs and How to Get Started
A focused, single-purpose Discord bot built on this stack runs $1.5K to $3K at MGT pricing. A complex bot with multi-server support, payment flows, or AI moderation runs $4K to $8K. The Discord bot services page has the full breakdown. If you have a specific bot in mind, the fastest path forward is a discovery call to scope it out. Most calls take 20 minutes and produce a concrete quote by the end.