Like I completely agree with your overall point about reckless overengineering, but you also just listed three true and really good reasons to avoid integrating Slack.
Like I completely agree with your overall point about reckless overengineering, but you also just listed three true and really good reasons to avoid integrating Slack.
No reason to use Slack when such options exist, but also no reason to write your own chat app, either.
If it takes you that many engineers you are either using the wrong software or using it incorrectly.
Adding to other large company problems, these people will need management layers, the team will need a charter for growth. Who wants to be the maintainer of the Mattermost servers in a large company? Add all of this up and then the slack deal starts to look reasonable.
Edit: Just to add some real numbers, slack costs $12.50 per user per month [1] - that is ~$750k per year for 5000 users = 5 engineers. (More like 3 really in the Bay area)
There's no way it suddenly needs a new team of dedicated full time resources.
There's no way a company with 5000 Slack users is paying the sticker price per head - they'll call Slack's enterprise sales team and negotiate some volume discount with whatever shiny enterprise-grade features, SLAs, support guarantees, etc. they need.
Moreover, email is hard and does require a dedicated team, but the order of magnitude is wrong here. 5 people is plenty.
These Bay Area tech people must be either incredibly inefficient (especially when comparing to what they get paid), or your estimate must be waaaaay off.
This is valid not just for Mattermost but many other apps that support sending e-mails. And that's why it's important that instead of giving up and outsourcing it, we all try to set it up and have first-hand experience in challenges we have to face in the process. Because if everybody just uses Mailgun & SES, in a decade or two it won't be be possible to set up your e-mail server anymore (of course you will be able to, but your e-mails won't reach most customers).
I ended up outsourcing DMARC report processing, if I wanted to do it in-house I'd have to setup and maintain an Elastic stack[1] which seems like huge overkill.
Unfortunately, I found this to already be somewhat of a reality. Even with all the best practices I went to, many MTAs simply don't trust my IP address. Most "sane" MTAs seem to greylist me rather than blacklist outright, so it just adds a bit of delay to users receiving their emails. Thankfully it seems to be gradually getting better, but gone are the days of simply pointing your apps at sendmail letting them go.
You'll find a lot of times the champion of the new hotness moves on and leaves someone else to maintain the old hotness at costs that were never factored into the original deployment.
As I noted in another comment, it's a trilemma where you have to pick and choose your battles. The initial deployment time is rarely the most important factor when introducing a new stack within an organization.
For example, large MMO guilds have a quite different regulatory environment from, say, a large healthcare organization in the US governed by HIPAA. It's an extreme example, sure, but a homegrown, dumbed down solution, might be the only way to ensure regulatory compliance.
It doesn't take a lot of imagination to come up with other scenarios. I can't defend Uber doing it because I'm not involved, but large MMO guilds are not archetypal of enterprise systems.
When OP says they built their own internal chat app, that's not entirely accurate - uChat is built upon Mattermost.
Mattermost has been rock solid for the last couple of years for my team BTW.
Compare with a small development team for a significant percentage of their time to build a halfway decent chat tool.
Miles of difference.