How to Build a Slack App as a Solo Developer
Complete guide to building a Slack app as a solo developer - tech stack, architecture, timeline, and tips.
What You're Building
A Slack app is a tool that lives inside Slack workspaces and does something useful for teams. Could be a standup bot, a customer support bridge, an analytics dashboard, or an automation tool. The beauty of building for Slack is that your distribution channel is built in. Teams already live in Slack, so you're meeting them where they are.
I built a simple Slack notification bot for one of my projects and was surprised at how straightforward the Slack API actually is. The documentation is solid, the SDKs are well-maintained, and you can have a basic bot responding to messages within an hour. The hard part isn't the Slack integration. It's figuring out what your app should actually do.
Difficulty & Timeline
| Aspect | Detail |
|---|---|
| Difficulty | Medium |
| Time to MVP | 3-5 weeks |
| Ongoing Maintenance | Medium |
| Monetization | Per-workspace subscription ($5-49/month), usage tiers |
Recommended Tech Stack
Node.js with Bolt (Slack's official framework), hosted on Railway or Render. Bolt handles all the Slack-specific plumbing like event handling, slash commands, modals, and OAuth installation flow. You focus on your app's logic, Bolt handles the Slack protocol.
The current Bolt for JavaScript release is @slack/bolt v4.7.3 (published 2026-05-27), and the package requires Node.js 18 or newer per its engines field. It is a genuinely popular foundation, with the slackapi/bolt-js repository sitting at roughly 2,900 GitHub stars and the package pulling about 3.3 million npm downloads in the last week (the week of 2026-05-22 to 2026-05-28). If you need lower-level access to Slack's Web API methods directly, @slack/web-api v7.16.0 is the underlying client Bolt builds on, and it sees around 11.8 million weekly downloads on its own. Pin these versions in your package.json so a surprise major bump does not break your install flow mid-launch.
Install it into a fresh project like this:
npm install @slack/bolt@4.7.3
Bolt reads two values from the environment in the default OAuth setup, your bot token (SLACK_BOT_TOKEN, the xoxb- token) and your app's signing secret (SLACK_SIGNING_SECRET) used to verify request signatures. If you develop over Socket Mode instead of a public HTTP endpoint, you swap the signing secret for an app-level token (SLACK_APP_TOKEN, the xapp- token). Keep all of these out of git.
For the database, Supabase or plain PostgreSQL. You need to store workspace installations, user preferences, and whatever data your app processes. Redis if you need queuing or caching for heavier workloads.
On hosting cost, both recommended platforms are cheap to start but neither runs a permanent free always-on web service anymore. Railway gives a one-time $5 trial credit and then its Hobby plan is $5/month (Pro is $20/month per seat), so budget at least the Hobby tier for a bot that needs to stay awake to receive Slack events. Check current pricing before you commit, since these tiers move.
Step-by-Step Plan
Phase 1: Slack Foundation (Week 1-2)
Create your app in the Slack API dashboard. Set up the OAuth flow so teams can install your app with one click. This is the part most tutorials gloss over, but it's critical. A broken installation flow means zero users.
Build your core interaction. If it's a slash command, get that working end to end. If it's a bot that responds to messages, wire up the event listeners. If it's a modal workflow, build the form and submission handler. Pick ONE interaction pattern and nail it.
Test in your own workspace first. Create a test Slack workspace (it's free) and install your app there. Break things here, not in someone else's workspace.
Phase 2: Core Logic (Week 2-4)
Now build the actual value. This is whatever your app does that people would pay for. A standup summary tool needs to collect responses and generate reports. A support bridge needs to route messages and track tickets. An analytics bot needs to pull data and format it nicely.
Whatever your core feature is, build it well. Make the messages look good. Use Slack's Block Kit for rich formatting. A well-formatted Slack message feels native and professional. A wall of plain text feels like spam.
Phase 3: Polish & Distribution (Week 4-5)
Build a landing page explaining what your app does. Include screenshots of the app in action inside Slack. Set up the Slack App Directory submission if you want organic discovery (the review process takes 1-3 weeks, so start early).
Add a settings page where workspace admins can configure the app. Even simple things like choosing which channel to post to or setting notification preferences make a big difference in perceived quality.
Key Features to Build First
OAuth installation flow. This is how teams add your app. Use Slack's official OAuth v2 flow. Store the access tokens securely.
Core interaction. One slash command, one bot response, or one modal flow. Whatever your app's main thing is.
Block Kit messages. Learn Block Kit early. Rich, formatted messages make your app feel polished and professional. Plain text messages feel cheap.
Error handling. Slack has a 3-second timeout for interactive responses. If your app takes longer, acknowledge immediately and follow up asynchronously. Getting this wrong makes your app feel broken.
Architecture Overview
Slack Workspace
└── Events/Commands -> Your Server (Bolt)
├── Event handlers
├── Command handlers
├── Modal submissions
├── Scheduled jobs
└── Database (PostgreSQL)
├── Installations (tokens per workspace)
├── User preferences
└── App-specific data
Slack sends HTTP requests to your server. Your server processes them and responds. That's the entire architecture. Keep it simple.
Common Pitfalls
Ignoring the 3-second rule. Slack's docs are explicit that your app must reply to the HTTP POST with a 200 OK within 3 seconds of receiving the payload, or the user sees an error. If your processing takes longer, immediately send the acknowledgment and then follow up with the actual result using response_url or chat.postMessage. Note that response_url is not unlimited, a slash command can be answered up to 5 times within 30 minutes via that URL, so plan your follow-ups accordingly. I made the 3-second mistake early and users thought the app was crashing.
Not handling workspace uninstalls. Teams will uninstall and reinstall your app. Handle the tokens_revoked and app_uninstalled events to clean up your database. Otherwise you'll have stale tokens and broken state everywhere.
Building too many features. Slack apps that try to do five things end up doing none of them well. The best Slack apps do one thing perfectly. Geekbot does standups. Donut does random coffee chats. Polly does polls. Pick one thing.
Ugly messages. If your bot sends plain text responses, it looks unprofessional. Invest time in Block Kit. Use sections, dividers, buttons, and context blocks. It takes an hour to learn and makes your app look 10x more polished.
Skipping the Slack App Directory. Yes, the review process is annoying. But the directory is free distribution to millions of Slack workspaces. Submit early and iterate based on reviewer feedback.
Timeline Estimate
| Phase | Time | What You're Doing |
|---|---|---|
| Slack setup & OAuth | 1-2 weeks | App creation, installation flow, basic interactions |
| Core logic | 2 weeks | Your app's main value proposition |
| Polish & submit | 1 week | Landing page, App Directory submission, testing |
| Total | 3-5 weeks | Ready for teams to install |
Common Errors and Fixes
These are the errors that actually show up when you wire Bolt to Slack for the first time, and what the official docs say to do about them.
dispatch_failed or "We had some trouble connecting" in the Slack client. This is the visible symptom of the 3-second rule. Slack tried to reach your handler, did not get a 200 OK in time, and surfaced the failure to the user. The fix is to acknowledge first and do the slow work after. In Bolt that means calling ack() at the very top of your listener, then sending results with say(), respond(), or client.chat.postMessage once the work finishes.
invalid_auth or not_authed when calling Web API methods. Your SLACK_BOT_TOKEN is missing, expired, or revoked, or you are passing a user token where a bot token is expected. Confirm the xoxb- token is loaded from the environment and that the workspace has not uninstalled the app. After a reinstall the token changes, so re-read it from your installation store rather than caching the old value.
missing_scope when a method call rejects. The bot token does not carry the OAuth scope that method requires. Add the scope under OAuth and Permissions in the app config, then reinstall the app to the workspace so the new scope is granted. Scopes are not retroactive, an existing token will not gain a scope until reinstall.
Request signature verification failures (401 from Bolt). When you host over HTTP rather than Socket Mode, Bolt verifies every request against SLACK_SIGNING_SECRET. A mismatch usually means the wrong signing secret, a body parser mangling the raw request body before Bolt sees it, or clock skew on your server beyond the allowed window. Use the signing secret from the Basic Information page exactly, and let Bolt's receiver handle the raw body rather than adding your own JSON middleware in front of it.
channel_not_found or not_in_channel when posting. The bot has to be a member of a channel to post to it (for public channels you invite it, for the chat.postMessage target you pass the channel ID, not the name). Invite the bot, or post somewhere it already has access.
Stale state after uninstall and reinstall. If you do not handle app_uninstalled and tokens_revoked, your installation store keeps a dead token and later calls fail with account_inactive or token_revoked. Subscribe to those events and delete the installation record when they fire.
Is This Worth Building?
Yes, especially if you've identified a specific workflow pain point that teams deal with daily. Slack apps have a fantastic distribution advantage. The App Directory puts you in front of millions of workspaces, and once a team installs your app and integrates it into their workflow, switching costs are high. That means low churn.
The pricing model works well too. Per-workspace subscriptions of $5-29/month add up quickly. 100 workspaces at $15/month is $18k/year, which is very achievable for a well-built Slack app solving a real problem. Just make sure the problem you're solving is one that teams encounter daily, not weekly or monthly. Daily usage drives retention.
Sources
All figures below were checked on 2026-05-30.
@slack/boltversion 4.7.3 and Node 18+ engine requirement, npm registry: registry.npmjs.org/@slack/bolt/latest@slack/boltweekly downloads (about 3.3M, week of 2026-05-22 to 2026-05-28), npm download API: api.npmjs.org/downloads/point/last-week/@slack/bolt@slack/web-apiversion 7.16.0 and weekly downloads (about 11.8M), npm: registry.npmjs.org/@slack/web-api/latest and api.npmjs.org/downloads/point/last-week/@slack/web-apislackapi/bolt-jsGitHub stars (about 2,900) and latest release v4.7.3 (2026-05-27), GitHub API: api.github.com/repos/slackapi/bolt-js- Bolt for JavaScript install and environment variables (
SLACK_BOT_TOKEN,SLACK_SIGNING_SECRET,SLACK_APP_TOKEN), official docs: docs.slack.dev/tools/bolt-js/getting-started - 3-second acknowledgment rule and
response_url(up to 5 responses in 30 minutes), Slack docs: docs.slack.dev/interactivity/handling-user-interaction - Railway pricing (Trial $5 one-time credit, Hobby $5/month, Pro $20/month per seat): railway.com/pricing
Like this? You'll like what I'm building too.
Two ways to support and get more of this work.
HEARTH
A privacy-first Life OS for your desktop. Journal, tasks, and notes that stay on your machine. Coming soon, direct download from this site.
Read moreMY TOOLKITS
Receipts-first toolkits for shipping after hours, building Claude agents, publishing on Amazon, and more. The exact methods I used, not theory.
Browse on WhopRelated Articles
Treating Video As Code With Remotion And fal
How I turned a script into a finished video with code instead of a timeline app, and why determinism is the real win for a solo dev.
Build Versus Buy For A Custom AI Feature
How to decide between an off-the-shelf AI tool and a custom AI feature, weighing control, cost, differentiation, and data with a clear framework.
Can One Developer Build Your Whole MVP
An honest look at whether a single full-stack developer can ship your whole MVP, when it works beautifully, and when you should bring in more people.