I switched our small consulting team’s chat off Slack about four months ago. The reason was not the price. The reason was that Slack had trained us into a state of low-grade anxiety: every ping meant something, and the only way to clear that anxiety was to scroll. We had eleven people on the team and a wall of unreads that nobody could plausibly answer. The replacement is Zulip, an open source threaded chat server (a self-hostable chat application where every conversation is a stream, and replies live under a topic inside that stream rather than in one flat channel). It is not a perfect tool. It changed how we work, and the change was almost entirely for the better.
Why Slack stopped working for us
Slack’s model is one flat channel per topic, with replies in line. If the channel is busy, replies get buried within hours. If the channel is quiet for a week, you scroll past ten days of “lol” and “sounds good” to find the decision that mattered. Slack added threads in 2014, but the company culture around them never really changed. Most of our team used threads inconsistently, and the inconsistent threads were worse than no threads, because now there was a second place to look.
We tried a few things before admitting Slack was the problem. We wrote a “Slack etiquette” doc. It helped for a week. We turned on Do Not Disturb hours. They got overridden the first time something actually mattered. We tried muting channels we did not need. The list of muted channels grew to fourteen, which meant the visible channels were either dead or noisy. None of this was Slack’s fault. It was the model.
What Zulip does differently
Zulip’s model is one stream per topic, with a topic inside the stream for each thread. Every message has a topic. Every reply lives under its topic. The stream is a folder. The topic is a subject line. The message is the email body, but it is a real-time chat. If you leave for a day, you scroll the stream you care about, read the topic headers, and click into the four that matter. You do not scroll nine hundred messages.
A short list of the things this changed for us:
- No more lost decisions. Topics are persistent. The decision from three weeks ago is still a topic, still searchable, still linked from the relevant PR.
- Catch-up is bounded. A bad day on Slack is 400 messages of scroll. A bad day on Zulip is 14 topics, each with 1-3 messages.
- Notifications are topic-level, not stream-level. You can mute a topic, mute a stream, or be notified for every message. Most of us mute everything except our name and direct messages.
- The mobile app is not a separate, worse experience. It shows you the streams, not a single inbox of doom.
The single biggest change was the last one. On Slack, the mobile app was where anxiety lived. On Zulip, the mobile app is where I read four topics and close it.
The migration was not bad
We self-hosted Zulip on a small Hetzner VPS for $4 a month, plus a Postgres database on the same box. The Zulip install is one bash script, and the docs are clear. Importing our Slack history was harder than installing the server. Zulip ships a Slack importer, and it works, but it imports everything into one giant stream with no topic structure, which is exactly the mess we were trying to leave. We let the import run, then archived the result.
What we kept:
- Search across the old history. The imported messages are still searchable, just not browsable.
- The user mapping. Names and avatars came over correctly.
- Nothing else. The chat history was, on inspection, mostly noise.
What we did not keep, and do not miss:
- Slack’s app directory integrations. A few of them (PagerDuty, GitHub) we re-created with Zulip’s incoming webhooks, which are a documented API endpoint that lets any service POST a message into a stream.
- Slack Connect channels for talking to outside clients. We moved two of those to email and one to a shared Zulip instance. The third client did not care which tool we used, as long as we answered.
What I would tell past me
If I could send a message back to the version of me that signed the Slack contract in 2022, I would say four things:
- Try the model for a week before judging it. Zulip feels weird on day one because topics feel heavy. By day seven you will not want to go back.
- Set the team policy in writing before you migrate. “We use topics for everything, no flat replies” is a one-line policy. Pin it in the first stream.
- Do not import the old history as a navigable resource. The import is a compliance feature, not a productivity one. Treat it as a backup.
- Self-hosting is fine for a small team. A 4 GB VPS runs Zulip for thirty users without breaking a sweat. You do not need Zulip Cloud unless you have a compliance reason.
Trade-offs
Zulip is not free in time. Self-hosting means you are on the hook for backups, updates, and the occasional Postgres tuning session. The Zulip team’s update cadence is roughly monthly, and the upgrade is usually a five-minute job, but it is still a job. Notifications are topic-aware but not as polished as Slack’s: if you are on three different topics across three streams, you will get three notifications, not one grouped one. The mobile app is good, not great, and the desktop app on Linux is a little behind the macOS app in features. Search is faster than Slack’s, but the query syntax is fussier, and the team spent two days complaining about it before they learned the syntax.
In our case, the math worked. We were paying about $8 per user per month for Slack, which was $7,000 a year for a team that did not need what Slack was selling. Zulip Cloud is $6.67 per user per month if you do not want to self-host, which is still cheaper. Self-hosting drops that to roughly the cost of a VPS, which is negligible. The migration took one weekend plus two weeks of “weird questions while we all learned the new tool.”
If you are a small team that is mostly internal and is being slowly ground down by Slack’s notification model, Zulip is a clear win. If you rely heavily on Slack Connect to chat with customers, or you have a deep investment in Slack-specific app integrations, the migration is real work and the math is different.
Bottom line
Slack is not bad software. It is the wrong model for a small team that does not need an always-on firehose. Zulip’s topic model is closer to email and closer to how knowledge actually gets accumulated. For our team, the change was the most positive workflow shift in five years. If you are at the point where Slack feels like a chore and not a tool, give Zulip a weekend. You can run it for free on your laptop with Docker. The first week is awkward. The second week is fine. By the third week, your team will ask you why you did not switch sooner.