Why we moved from Slack to Discord?
Slack limitations
Stewart Butterfield created slack to meet the needs of companies. It's an excellent communication tool that has successfully found its place in companies at all stages. From R&D to marketing to finance, Slack is omnipresent. However, like all tools, it is not perfect. In teamwork, it is perfectible, and in community management, it is non-existent.
Here are the 3 limitations that pushed us to look for something else (from the most important to the least important):
- You have to pay the 10,000 message limit per user to avoid losing your message history; it's genuinely restrictive! You have to pay per user on your Slack to make it disappear. Please do the math; for a community of 1000+ developers, it's pretty expensive.
- We are a "remote first" company - we need to be able to talk to each other quickly and to be able to share our screen very often; with Slack, it's a real pain in...
- There is no member hierarchy - It's impossible to know who's in the staff, an active member, and a beta tester. It's hard to know who is who and who does what. How do you give visibility to new members? It's simply not possible.
After testing several solutions such as Tandem, Zoom, Google Meet, Slack, each answer was able to satisfy one or two points, but never all of them... Until we found Discord.
Discord
Built for online community
Discord is a communication tool that has been created for online gamers. Online gamers have high expectations. Written and voice communication is ubiquitous and must be flawless for them. It is in this context that Discord was made. The funny part is, it is also ideally suited for team communication in a company. And even more so when this company targets developers, which is essentially a world of enthusiasts. The community can meet and talk on Discord in a very natural way. The experience is intuitive.
Advantages over Slack
Here are the advantages of using Discord:
- No more 10,000 message limit - you don't even have to pay; Discord won't limit you. All the features are accessible without spending 1 cent. It's pretty incredible considering the quality of the product.
- Video and Voice conversations - Discord is excellent at supporting video and audio communication. There are no limits on this side either. Want to organize a quick meeting? Just go to a voice channel, and it's done.
- Hierarchy - In a company, as in a community, not everyone has the same status. Discord has perfectly understood this and materializes it through the role system. Each member can have zero to many roles (R&D Engineer, Marketing, Finance, Founder, Contributor...). Each channel will then be accessible or not according to its roles. This is very practical to make only some channels accessible to the community and the rest to the staff.
Discord sets the standard very high! The tool was designed with the idea of improving teamwork - obviously on the gaming side. But this is perfectly transposable to the needs of companies. Today online games are taken very seriously and are considered an actual business activity. Pricing is another significant point; let's talk about it...
Interesting pricing model
At Qovery, we have no problem paying for the tools we use. The problem is that we can't afford a tool that charges us a per-user license fee! This is where Discord stands out from its competitors by offering to price to the global "server" rather than to the user. By the way, if you don't want to do HD voice communication no need to pay. It's a very virtuous and collaborative pricing model. Because your users can help you pay the bill at their convenience. In our case, we pay $74.85/month for +150 developers. And even if tomorrow we're at 100,000 developers, it won't change anything on the bill! Incredible, isn't it?
Missing features from Slack :'(
Telling you that being in Discord is heaven on earth would be a lie. It lacks some essential features to make Discord the uncontested leader :)
- Integrations: Discord was created for gamers, which means you won't find all the integrations you have for Slack. That's the big negative! However, you can manage your integrations yourself, thanks to webhooks. Thanks to this, we were able to (almost) upload all the integrations we had on Slack (Stripe, Intercom, Mailchimp, Typeform, and Gitlab) - a few of them are still in progress.
- Thread messages: Discord does not allow threaded chat; even if the community requests access to this feature, there are no plans at this time. On the other hand, there is the possibility to "quote" a message.
- Gaming-oriented: As I said above, Discord was made for gamers. This means that sometimes specific usage options are not appropriate. Nothing too serious, but it can be confusing if you're planning to get people from other departments than R&D in there.
What's next?
At Qovery, we are pleased with this change, especially in these dire times due to the Covid-19. Discord is, for us, very appropriate for our default remote office needs. We lack sufficient hindsight to tell you this on the community side, but the first feedback is positive. We will keep you informed of how the product evolves. We secretly hope that Discord will consider that their product can be an alternative to Slack for business.
.svg)
.svg)
.svg)
Suggested articles
The cluster coming up is the easy part. What catches teams off guard is what happens six months later: certificates expire without a single alert, node pools run at 40% over-provisioned because nobody revisited the initial resource requests, and a manual kubectl patch applied during a 2am incident is now permanent state. Agentic control planes enforce declared state continuously. Monitoring tools just report the problem.
The instinct when setting up Kubernetes observability is to instrument everything and send it all to your APM vendor. That works fine at ten nodes. At a hundred, the bill becomes a board-level conversation. The less obvious problem is the fix most teams reach for: aggressive sampling. That is how intermittent failures affecting 1% of requests disappear from your monitoring entirely.
Scaling your deployments to zero is only half the battle. If your cluster autoscaler does not aggressively bin-pack and terminate the underlying worker nodes, you are still paying for idle metal. True environment sleeping requires tight integration between your ingress layer and your node provisioner to actually realize FinOps savings.
The structure, table, tool list, and code blocks are all worth keeping. The main work is fixing AI-isms in the prose, updating the case study to real metrics, correcting the FAQ format, and replacing the CTAs with the proper HTML blocks. The tool descriptions need the "Core strengths / Potential weaknesses" headers made less template-y, and the intro needs a sharper human voice.
For years, Red Hat OpenShift has been the safe choice for heavily regulated, on-premise environments. It operates as a secure fortress. But in the public cloud, that fortress acts as an expensive prison. Paying proprietary per-core licensing fees on top of your standard AWS or GCP compute bill is a redundant "middleware tax." Escaping OpenShift requires decoupling your infrastructure from your developer experience by running standard, vanilla Kubernetes paired with an agentic control plane.
Agentic Kubernetes resource reclamation is the practice of using an autonomous control plane to continuously identify, suspend, and delete idle infrastructure across a multi-cloud Kubernetes fleet. It replaces manual cleanup and reactive autoscaling with intent-based policies that act on business state, eliminating the configuration drift and cloud waste typical of unmanaged fleets.
Kubernetes focuses on container orchestration, but the reality on the ground is far less forgiving. Provisioning a single cluster is a trivial Day-1 exercise. The true operational nightmare begins on Day 2. Teams that treat multi-cloud fleets like isolated pets inevitably face crushing YAML configuration drift, runaway AWS bills, and severe scaling bottlenecks.
.webp)