I'm with you on the frustration with Slack and every month when I see our bill I consider forcing the company to change.
My co-founder and I tried moving to Google Chat. We already pay for workspace so why not.
What kept us on slack is the external partners who are on slack.
This is a bigger deal than you might think.
Google chat doesn't allow you to add external members unless they were added at the creation of the channel. Seems like a strange limitation.
I don't even think the slack search is really that much of a value add.
We split our meeting between huddles, usually when there is only two or three of us, or google meet.
We're also more than 5, but to be clear. Your pricing is the pricing for the team, not per user?
I wish you all the best, and I'd be keen to try it as we only currently have 3 external partners, but if you can nail that management of external users, I think that is important.
I'm also assuming there are desktop/mobile/web apps? Also necessary, though also a lot of overhead for a small team.
Pricing: Yes, exactly. It is a flat fee for the whole team. $15/month covers your entire group (up to 20 people). No per-seat billing. We hate that "tax" as much as you do.
External Partners: You hit the nail on the head. We are building "Guest Access" so you can invite external partners to specific channels (single-channel guests) easily.Since we don't charge per-seat, adding a few clients/partners won't blow up your bill like it does on Slack.
Apps: We are launching as a high-performance PWA (Web) first. It installs to your dock/home screen and feels native, but allows us to iterate faster than maintaining three separate codebases. Native wrappers are coming, but we want the core experience to be rock solid first.
I don't think you can ignore mobile, particularly wrt notifications. I'm not sure if the app stores are as aggressive in restricting wrapped apps as they used to be.
Agree with the sentiment here. On top of this, something very important are integrations.
We use a lot of tools that send messages to dedicated Slack channels for notifications. CI failures, incidents, etcs. They use probably Slack API that you can replicate, but the integrations are native in other services ("Click to connect to Slack"). Without that, you are in a big disadvantage.
> Google chat doesn't allow you to add external members unless they were added at the creation of the channel. Seems like a strange limitation.
Google chat doesn't allow you to change whether external members are allowed to join after creation of the channel, but if you enabled that you can add/remove them at any time.
> What kept us on slack is the external partners who are on slack. This is a bigger deal than you might think.
We are there as well. Most partners and clients use Windows. Most of them therefore had exchange and moved to the cloud. Most of them got 'Teams' for free in the package, chat and meetings.
Now we see a zoom link and go 'euuuuugh', yuck. hipster yuck.
Give me Teams
Upsides seem to be, its back to xmpp where we can communicate with anyone
Screw teams. I had a meeting on teams for the first time ever so I decided to use safari, my designated un touched browser on my mac, to use teams in order to maximize compatibility. The thing kept shutting off my webcam every two seconds. I’d turn it on then it would shut off two seconds later. We switched to zoom for the remainder of the meeting.
Google’s offering isn’t much better either. I tried the same thing, going with safari, tested my connection, all was well. Then came time to share screen. No go! Kept complaining I need to enable permissions in safari for hangout that were already enabled.
I feel the same way when I get an email with a Teams link, but I think we're all just going to have to live with the idea that everyone is on different platforms.
This just goes to show how badly Microsoft (or other owners before) messed up with skype. They had an opportunity to own the entire thing.
All the cross tenant inconsistency really needs to be ironed out, I'm not sure if it's just my org but half the features of calls are randomly disabled or enabled based on who originated it.
My favorite was when I entered VR during our standup on our otherwise quite locked down and very corporate environment.
> Free forever for teams up to 5. Unlimited search, unlimited history.
I understand the strategic value of offering unlimited features to differentiate from competitors like Slack, might drive some amount of anxiety. Buyers may question long-term sustainability or fear undisclosed "shadow" caps.
Since engineering limits are inevitable to prevent abuse (especially on free accounts), it might be better to set specific, generous expectations upfront. For example, 2 years of freeform search plus unlimited "tagged" (i.e. Decision Inbox) search. This avoids the skepticism that comes with promising "no limits" forever. It also avoids the trap of needing to announce a change later with predictably negative reactions.
If you do want to offer unlimited, then planning ahead with hard-to-hit-unless-you're-trying messages/hr limits might help you tame growth and avoid abuse. My initial thought when seeing unlimited anything is "I could write a filesystem on top of that" - especially if you allow attachments. :P
Great point. We’re launching with a clear Fair Usage Policy to address exactly that—preventing abuse (like the "filesystem" hack) while keeping it truly unlimited for actual team communication. Our cost structure is different than legacy players; because we’re built on Cloudflare + our custom CRDT-hybrid store, the overhead for storing and searching text is low enough that we can avoid those arbitrary 90-day or 2-year cutoffs without it being a sustainability risk. We’ll be publishing our explicit "human use" guidelines on the site soon so there’s no "shadow" cap anxiety for legitimate teams.
Your costs will change and shift over time. Personally, I don't trust anything that says "Free Forever" or "Unlimited". Give a real limit and figure out the transition. "Free now, and no plans to change, but if it does, we will give you one year to transition" is much more confidence building then "Free forever".
I run a company that services 1,000+ clients on Slack, another 300+ on Teams, and a < 100 on Email/Gchat
I wouldn't wish Teams on my worst enemy, so in that regard, I love Slack
The thing I struggle with the most is how I'd move all of our core functionality from Slack. A lot of the people/teams that build these "Slack killers" I don't think have ever run Slack at scale
How are you going to replace the 30+ in-house apps I've built that automate 50+ workflows?
How are you going to replace the 100+ workflows I use with 1,000+ clients when they have to submit a ticket, or questionnaire, or a security event?
How are you going to replace the 100+ partner channels I have where we send out automated messages about specials and discounts we're running?
What about the 500+ other apps I run that integrate with our systems? Are they going to support your new platform?
Do you have retention settings? DLP? How granular can I go on permissions? What about picking up events via the API so I can train people in real time on what not to do in public channels?
I have no affinity or personal ties to Slack. But if you're going to position yourself as a Slack competitor you have to actually do what Slack does
Feels like the more important question is how are you going to do all these things when Slack cuts you off, or there is some new Slack policy that prevents it, or they increase their pricing by 1000%
Haven’t you basically built your entire business on this singular proprietary platform they you have almost no control over?
> Feels like the more important question is how are you going to do all these things when Slack cuts you off
I pay Slack $50k/year. They have no reason to shut me off.
> or there is some new Slack policy that prevents it
Prevents what exactly? The new API pricing they introduced doesn't apply to internal apps. I suppose they could apply it to internal apps. We'd have to figure out a path around it
> or they increase their pricing by 1000%
1000% increase in pricing seems incredibly unlikely. That would not only disrupt thousands of companies but would likely kill Slack entirely
---
> Haven’t you basically built your entire business on this singular proprietary platform they you have almost no control over?
Not really. We service clients through Slack. Could we switch? Sure. Would it be a pain? Yeah. Would it be costly? Yeah.
But there's also no reason to switch. And if a new platform comes out (like the one this thread is about), I would expect them to have the features to compete with Slack if they are posiitioning themselves as a Slack competitor
Disclaimer: I'm developing a chat app/serivce as well, but it's not a Slack/Teams competitor.
I personally would love to see real alternatives to Slack and Teams.
Discord has Stoat (formerly "Revolt") and a newer app called "Root" but both of those have a long way to go to replace Discord.
Maybe I am atypical, but to me the biggest problem with Slack is not the 90-day retention (because I would assume any paid version should include message retention), but rather the per-user pricing.
Given your current pricing (at least what you show right now), it seems like your team-based pricing model is a much better selling point for your service over something like Slack or Teams which use per-user pricing, assuming you offer most of the features that typical Slack/Teams clients need.
The only issue I see with pricing is your free tier might ultimately undermine your revenue since the only differences between it and the first paid tier are 15 more users and priority support (which most people should never need).
That is a really sharp observation. In a traditional SaaS architecture built on standard, expensive managed services (like RDS or Elasticsearch), you'd be 100% right—a free tier this generous would be a financial liability.
But that’s exactly why we spent months building our core infrastructure from the ground up rather than just assembling off-the-shelf open source or paid components. We made the deliberate architectural choice to develop and optimize our storage and sync engine to drive the marginal cost of a free workspace down to near-zero.
Because our cost basis is structurally lower than competitors carrying legacy tech debt or generic cloud overhead, we can afford to treat the free tier as a sustainable on-ramp rather than a loss leader that bleeds us dry.
I don't know if I like the marketing. A deeply discounted product obviously has some appeal, but it's at odds with the "chat that just works" messaging that suggests an advantage in reliability or UI and that will realistically take time to mature enough to be at parity, let alone ahead.
That’s a fair critique if the goal was 1:1 feature parity with Slack (2,400+ integrations, workflows, huddles, etc). If that is the definition of maturity, we will indeed never catch up—and that is by design.
As an ex-Salesforce team, we are well aware of the legacy architecture constraints that Slack operates under and how that drives up their infrastructure costs per user.
We spent months building a custom sync and storage engine from the ground up specifically to avoid that legacy tax. Our pricing isn't a 'deep discount' strategy to mask lower quality; it reflects the fact that our structural cost to store and search text is orders of magnitude lower than the incumbents.
We aren't trying to build a 'cheaper Slack clone' with all the same bells and whistles, we are building a focused, high-performance tool for teams that just want the core communication experience to work perfectly, without paying for the decade of technical debt.
That's a fair point! While we default to unlimited history (since the 90-day hard limit is a pain for most), we plan to let admins set custom retention policies. If you want messages to auto-delete after 90 days to keep things ephemeral, you'll be able to configure that. We don't want to force 'chat as docs' on teams who prefer it temporary.
> Our technical infrastructure is our secret weapon. We're built from the ground up on Cloudflare's global edge network using reactive systems and local-first architecture. With modern, secure network protocols, we've reduced infrastructure costs by 100x compared to Slack or Teams. Their systems were built over a decade ago on legacy infrastructure that can't be easily modernized. We started fresh—and pass those savings directly to you.
...but this doesn't pass the sniff test. Cloudflare's products are value-add on value-add, they're a long way from raw infrastructure costs. At a small scale the fact you can pay as you go might mean they're cheaper than VMs or machines to get a good UX, but at scale they're hugely expensive.
Their technical infrastructure sounds like their Achilles heel in the long run.
I appreciate the skepticism—usually 'Managed Platform' does imply a heavy markup over raw compute. But for a chat application specifically, the math leans heavily in favor of Cloudflare Workers (Isolates) over traditional VMs/Containers.
You mentioned scale: Cloudflare's free tier covers the first 100k requests/day, but the paid tier is where the economics really shine at scale. We pay roughly $0.30 per million requests
In the traditional architecture (Slack/Teams), you pay for provisioned capacity to handle peak load. That means you are paying for massive EC2 clusters and RDS instances 24/7, even when usage dips at night. You pay for the idle time.
With Cloudflare Workers, we pay strictly for execution time. Chat is incredibly bursty and text data is small. If no one is typing, our infrastructure cost is literally $0. We don't pay for idle CPU.
Even at scale, the cost of executing a Worker for a few milliseconds to route a JSON packet is significantly lower than the Total Cost of Ownership (TCO) of maintaining a global fleet of VMs, load balancers, and a DevOps team to manage Kubernetes. We trade 'raw metal' efficiency for 'operational' efficiency, which is where the real savings are
I still think you're looking at this from a very small perspective (and to be clear, to begin with that may be the right call, it'll just bite badly at some scale).
It isn't about the cost of processing one message, it's about the cost of processing a thousand a second, or a million a second.
Fundamentally, Cloudflare make their money by taking raw infrastructure, slicing it into a million tiny pieces, paying 2-5x overhead to be able to do that, but then pricing each at 10-100x the cost to serve. It's cheap per request, per message, etc, but it's an incredibly expensive way to rent the infrastructure.
It's also a false dichotomy to say that the alternative is provisioning for peak load. There are many points on the spectrum, from Cloudflare's offering which is about as "serverless", high level, and expensive as you can get, through to buying your own servers.
Chat isn't really "bursty" at scale, it's more seasonal on a daily/weekly basis. That's pretty easy to scale over time on any cloud provider. Autoscaling groups were pretty much designed for this. GKE Autopilot is a more modern version, but there are lots of ways to do it.
I know as a startup it's important to optimise for right now, and CF might well be the best option for you. But I stand by this being your Achilles heel, it's a very expensive way to run the infra, and when you're delivering 1m messages a second, that's approaching a $1m/month bill just for request processing, let alone storage, indexing, etc.
But the per-request cost is not the only one. You're also paying $0.02 per million CPU-microseconds. If you do the math, that's easily double or triple the equivalent hourly charge for VM instances from the various major cloud providers.
For now, you're benefiting from the zero idle charges and Cloudflare's generous free allowance, because you're at a small scale. As you get bigger, the effect of those factors -- as a fraction of your total spending -- will decrease by a lot, and you'll still be paying the inflated unit costs.
This sounds reasonable (and the 30 microcents per request is pretty cool), but I wonder how do you handle storage and indexing. It still costs you, even when no one is typing.
Not the OP, but I’m assuming they meant end-to-end-encryption.
The company (customer) would be able to see their chats, but the provider (Dock) would not. I don’t think you’d need to have the encryption on a per-user level, but you could. The main point being that the customer’s chats would only be visible to them, not Dock. It would make some features more difficult though, namely search.
I’m not sure it’s entirely required, but I’d expect it as an option in the non-free tiers.
e2ee makes it hard to do things like “search” which is important for working with teams. For personal messengers usually search is all on device w an encrypted index, once an org grows beyond 50 people that sort of thing breaks down.
We take security very seriously (encryption in transit + at rest, SOC 2 based infra and GDPR compliance). We considered default E2EE, but currently, it introduces significant friction for features like instant server-side search (our core value prop vs Slack's hidden history) and simple multi-device onboarding without key management headaches. We are exploring E2EE for specific "Secure Channels" as a future feature, but for the general workspace, we prioritize a seamless "it just works" experience with standard high-security industry practices.
Just another SaaS whose promises we are forced to trust, but have no way of ensuring they keep them. No self-hosting option?
I really don't aee how anyone would migrate to this. The "bloat" of Slack is also years of people making third-party integrations work, which Dock will probably never have until and unless it gains a significant amount of regular users.
Matrix is technically impressive, but the friction for non-technical teams is still too high.
We are building for the teams that just want to sign up and start working immediately, without choosing a homeserver, verifying keys across devices, or dealing with the UI quirks of federated clients.
Our bet is that a vertically integrated, highly polished UX ("It just works") is the differentiator. We want to be the choice for teams that want the experience of Slack without the bloat, rather than just the protocol of chat.
For example, a 10-person marketing agency in France just needs to collaborate on campaigns today, they shouldn't have to understand the Matrix protocol or manage server infrastructure to get started.That's simply not their core business.
i use slack with one other person. we've been using it for 10 years. we pay every once in a while and download our archives. but i haven't found anything that's as useful, media-friendly, preview-friendly, and thread friendly as slack. we keep looking, but we always stay on slack.
Legal would probably tell you to purge anything older than 180 days, unless there is active discovery for a lawsuit, in which case retain until end of law suit. Retention is a legal policy issue, which may vary from company to company, and change when a new GC onboards. That should be driving the technical requirements.
My co-founder and I tried moving to Google Chat. We already pay for workspace so why not.
What kept us on slack is the external partners who are on slack. This is a bigger deal than you might think.
Google chat doesn't allow you to add external members unless they were added at the creation of the channel. Seems like a strange limitation.
I don't even think the slack search is really that much of a value add.
We split our meeting between huddles, usually when there is only two or three of us, or google meet.
We're also more than 5, but to be clear. Your pricing is the pricing for the team, not per user?
I wish you all the best, and I'd be keen to try it as we only currently have 3 external partners, but if you can nail that management of external users, I think that is important.
I'm also assuming there are desktop/mobile/web apps? Also necessary, though also a lot of overhead for a small team.
Notifications need to be solid as well.
We use a lot of tools that send messages to dedicated Slack channels for notifications. CI failures, incidents, etcs. They use probably Slack API that you can replicate, but the integrations are native in other services ("Click to connect to Slack"). Without that, you are in a big disadvantage.
But good luck!
Google chat doesn't allow you to change whether external members are allowed to join after creation of the channel, but if you enabled that you can add/remove them at any time.
We are there as well. Most partners and clients use Windows. Most of them therefore had exchange and moved to the cloud. Most of them got 'Teams' for free in the package, chat and meetings.
Now we see a zoom link and go 'euuuuugh', yuck. hipster yuck.
Give me Teams
Upsides seem to be, its back to xmpp where we can communicate with anyone
Downside is, its total lock-in to microsoft.
Google’s offering isn’t much better either. I tried the same thing, going with safari, tested my connection, all was well. Then came time to share screen. No go! Kept complaining I need to enable permissions in safari for hangout that were already enabled.
Zoom just works on the other hand.
This just goes to show how badly Microsoft (or other owners before) messed up with skype. They had an opportunity to own the entire thing.
My favorite was when I entered VR during our standup on our otherwise quite locked down and very corporate environment.
I understand the strategic value of offering unlimited features to differentiate from competitors like Slack, might drive some amount of anxiety. Buyers may question long-term sustainability or fear undisclosed "shadow" caps.
Since engineering limits are inevitable to prevent abuse (especially on free accounts), it might be better to set specific, generous expectations upfront. For example, 2 years of freeform search plus unlimited "tagged" (i.e. Decision Inbox) search. This avoids the skepticism that comes with promising "no limits" forever. It also avoids the trap of needing to announce a change later with predictably negative reactions.
If you do want to offer unlimited, then planning ahead with hard-to-hit-unless-you're-trying messages/hr limits might help you tame growth and avoid abuse. My initial thought when seeing unlimited anything is "I could write a filesystem on top of that" - especially if you allow attachments. :P
I wouldn't wish Teams on my worst enemy, so in that regard, I love Slack
The thing I struggle with the most is how I'd move all of our core functionality from Slack. A lot of the people/teams that build these "Slack killers" I don't think have ever run Slack at scale
How are you going to replace the 30+ in-house apps I've built that automate 50+ workflows?
How are you going to replace the 100+ workflows I use with 1,000+ clients when they have to submit a ticket, or questionnaire, or a security event?
How are you going to replace the 100+ partner channels I have where we send out automated messages about specials and discounts we're running?
What about the 500+ other apps I run that integrate with our systems? Are they going to support your new platform?
Do you have retention settings? DLP? How granular can I go on permissions? What about picking up events via the API so I can train people in real time on what not to do in public channels?
I have no affinity or personal ties to Slack. But if you're going to position yourself as a Slack competitor you have to actually do what Slack does
Haven’t you basically built your entire business on this singular proprietary platform they you have almost no control over?
I pay Slack $50k/year. They have no reason to shut me off.
> or there is some new Slack policy that prevents it
Prevents what exactly? The new API pricing they introduced doesn't apply to internal apps. I suppose they could apply it to internal apps. We'd have to figure out a path around it
> or they increase their pricing by 1000%
1000% increase in pricing seems incredibly unlikely. That would not only disrupt thousands of companies but would likely kill Slack entirely
---
> Haven’t you basically built your entire business on this singular proprietary platform they you have almost no control over?
Not really. We service clients through Slack. Could we switch? Sure. Would it be a pain? Yeah. Would it be costly? Yeah.
But there's also no reason to switch. And if a new platform comes out (like the one this thread is about), I would expect them to have the features to compete with Slack if they are posiitioning themselves as a Slack competitor
I personally would love to see real alternatives to Slack and Teams.
Discord has Stoat (formerly "Revolt") and a newer app called "Root" but both of those have a long way to go to replace Discord.
Maybe I am atypical, but to me the biggest problem with Slack is not the 90-day retention (because I would assume any paid version should include message retention), but rather the per-user pricing.
Given your current pricing (at least what you show right now), it seems like your team-based pricing model is a much better selling point for your service over something like Slack or Teams which use per-user pricing, assuming you offer most of the features that typical Slack/Teams clients need.
The only issue I see with pricing is your free tier might ultimately undermine your revenue since the only differences between it and the first paid tier are 15 more users and priority support (which most people should never need).
But that’s exactly why we spent months building our core infrastructure from the ground up rather than just assembling off-the-shelf open source or paid components. We made the deliberate architectural choice to develop and optimize our storage and sync engine to drive the marginal cost of a free workspace down to near-zero.
Because our cost basis is structurally lower than competitors carrying legacy tech debt or generic cloud overhead, we can afford to treat the free tier as a sustainable on-ramp rather than a loss leader that bleeds us dry.
As an ex-Salesforce team, we are well aware of the legacy architecture constraints that Slack operates under and how that drives up their infrastructure costs per user.
We spent months building a custom sync and storage engine from the ground up specifically to avoid that legacy tax. Our pricing isn't a 'deep discount' strategy to mask lower quality; it reflects the fact that our structural cost to store and search text is orders of magnitude lower than the incumbents.
We aren't trying to build a 'cheaper Slack clone' with all the same bells and whistles, we are building a focused, high-performance tool for teams that just want the core communication experience to work perfectly, without paying for the decade of technical debt.
> Our technical infrastructure is our secret weapon. We're built from the ground up on Cloudflare's global edge network using reactive systems and local-first architecture. With modern, secure network protocols, we've reduced infrastructure costs by 100x compared to Slack or Teams. Their systems were built over a decade ago on legacy infrastructure that can't be easily modernized. We started fresh—and pass those savings directly to you.
...but this doesn't pass the sniff test. Cloudflare's products are value-add on value-add, they're a long way from raw infrastructure costs. At a small scale the fact you can pay as you go might mean they're cheaper than VMs or machines to get a good UX, but at scale they're hugely expensive.
Their technical infrastructure sounds like their Achilles heel in the long run.
You mentioned scale: Cloudflare's free tier covers the first 100k requests/day, but the paid tier is where the economics really shine at scale. We pay roughly $0.30 per million requests
In the traditional architecture (Slack/Teams), you pay for provisioned capacity to handle peak load. That means you are paying for massive EC2 clusters and RDS instances 24/7, even when usage dips at night. You pay for the idle time.
With Cloudflare Workers, we pay strictly for execution time. Chat is incredibly bursty and text data is small. If no one is typing, our infrastructure cost is literally $0. We don't pay for idle CPU.
Even at scale, the cost of executing a Worker for a few milliseconds to route a JSON packet is significantly lower than the Total Cost of Ownership (TCO) of maintaining a global fleet of VMs, load balancers, and a DevOps team to manage Kubernetes. We trade 'raw metal' efficiency for 'operational' efficiency, which is where the real savings are
It isn't about the cost of processing one message, it's about the cost of processing a thousand a second, or a million a second.
Fundamentally, Cloudflare make their money by taking raw infrastructure, slicing it into a million tiny pieces, paying 2-5x overhead to be able to do that, but then pricing each at 10-100x the cost to serve. It's cheap per request, per message, etc, but it's an incredibly expensive way to rent the infrastructure.
It's also a false dichotomy to say that the alternative is provisioning for peak load. There are many points on the spectrum, from Cloudflare's offering which is about as "serverless", high level, and expensive as you can get, through to buying your own servers.
Chat isn't really "bursty" at scale, it's more seasonal on a daily/weekly basis. That's pretty easy to scale over time on any cloud provider. Autoscaling groups were pretty much designed for this. GKE Autopilot is a more modern version, but there are lots of ways to do it.
I know as a startup it's important to optimise for right now, and CF might well be the best option for you. But I stand by this being your Achilles heel, it's a very expensive way to run the infra, and when you're delivering 1m messages a second, that's approaching a $1m/month bill just for request processing, let alone storage, indexing, etc.
But the per-request cost is not the only one. You're also paying $0.02 per million CPU-microseconds. If you do the math, that's easily double or triple the equivalent hourly charge for VM instances from the various major cloud providers.
For now, you're benefiting from the zero idle charges and Cloudflare's generous free allowance, because you're at a small scale. As you get bigger, the effect of those factors -- as a fraction of your total spending -- will decrease by a lot, and you'll still be paying the inflated unit costs.
The company (customer) would be able to see their chats, but the provider (Dock) would not. I don’t think you’d need to have the encryption on a per-user level, but you could. The main point being that the customer’s chats would only be visible to them, not Dock. It would make some features more difficult though, namely search.
I’m not sure it’s entirely required, but I’d expect it as an option in the non-free tiers.
I really don't aee how anyone would migrate to this. The "bloat" of Slack is also years of people making third-party integrations work, which Dock will probably never have until and unless it gains a significant amount of regular users.
stable protocol, ability to federate, rooms/channels... what is lacking?
We are building for the teams that just want to sign up and start working immediately, without choosing a homeserver, verifying keys across devices, or dealing with the UI quirks of federated clients.
Our bet is that a vertically integrated, highly polished UX ("It just works") is the differentiator. We want to be the choice for teams that want the experience of Slack without the bloat, rather than just the protocol of chat.
For example, a 10-person marketing agency in France just needs to collaborate on campaigns today, they shouldn't have to understand the Matrix protocol or manage server infrastructure to get started.That's simply not their core business.
i use slack with one other person. we've been using it for 10 years. we pay every once in a while and download our archives. but i haven't found anything that's as useful, media-friendly, preview-friendly, and thread friendly as slack. we keep looking, but we always stay on slack.
(Not a lawyer, and thankfully, never deposed.)