Hacker News Reader

Comment by dahart | Hacker News Reader

The author's expectations just seem wildly unrealistic, I can't find much sympathy. Signed up for a pay service with a clear limit on the trial, yet was surprised by the limit, even though he knew how many Slack users he had and knew or should have known how many messages per day they were already sending. Put his community (customers) of thousands on the Slack team, even though the advertising and economics only make sense for internal teams. He is trying so hard to make his own mistake sound like Slack's fault.

Also, previous discussion: https://news.ycombinator.com/item?id=9754626

View on HN

You appear to be confusing the message archive limits with the number of user limits. The first is (loudly) disclosed. The second, apparently not.

Slack doesn't advertise as a chat for thousands of users, but teams of 5 to 50, worse case 100 people. It's "lucky" they didn't hard code a limit.

They did hard code a limit, the API has a specific error for that. They just choose not to disclose it, and to advertise with the phrase "Slack is free to use for as long as you want for teams of all sizes."

Well then I guess they expect the word "team" should be self explanatory... Maybe it's not.

This is a completely legitimate point. They are expecting "team" to be self explanatory, and it is a vague term that is not self-explanatory. If there's a size limit, it would be best if they stated that plainly.

But, come on, you have to admit that an online community of thousands of people does not fit even the most charitable interpretation of the word "team".

> But, come on, you have to admit that an online community of thousands of people does not fit even the most charitable interpretation of the word "team".

That is basically what the whole thread and article evolves about. Are 10k people a team? Really? Sure, you can argue all day that technically it may be the case, the whole world could be my team, some kind of super team and so a service shouldn't make any assumptions and so on, but reality is that everyone who hears "team" has a pretty good idea of a ball park figure how many people that will be and that freecodecamp doesn't fit into this. So, in the end it's just playing around semantics "but, but, but ... you said of any size .."

The whole world is not a team. You can only say that if you're making an intentionally, consciously hyperbolic statement.

I am not interested in long and un-ending pedantic arguments about the extreme corner-case definitions of words. I maintain that an online community of 10k people does not fit even the most charitable meaning of a working "team". If that doesn't work for you, then you're only setting yourself up for surprise.

This argument that "any size" should really mean "any size" amounts to someone walking into an "all-you-can-eat" buffet and expecting to be able to sit at the same table for 2 weeks eating all meals for the price of one, and then complaining that the 'all you can eat' advertisement should overrule all other policies the restaurant has.

It would be the same as someone seeing an ad for mini-golfing for $20 for a family of any size, and then bringing four thousand of your 2nd, 3rd, and 4th cousins, and demanding that the entire group gets in for $20. While there's a pedantic, technical truth to cousins belonging to your 'family', it doesn't meet anybody's common understanding of what an ad for family prices means, even the person trying to cheat the system.

If the author truly didn't even suspect that his 10k users is a massive stretch of the idea of a "team", the message limits should have been a clue, but instead of acknowledging he was pushing the limits, he blamed Slack.

"For teams of all sizes" is pretty deceptive. Even if the limit was disclosed somewhere deeper, advertising with a fundamentally inaccurate line is unfortunate.

While their language was poorly chosen, I think what Slack meant was that their free tier was under no additional restrictions than their paid tier for team size, which seems reasonable.

And signing people up with an undocumented API that skips a big amount of signup friction seems like a recipe for running into undocumented limits. Would we be upset with Slack for not supporting 1 million user teams? 1 billion? 1 trillion?

640k should be enough for anybody

At a "team" size of 5000, the 10000-message limit means you each get 2 messages before things start disappearing. So I think the message limit pretty strongly implies a team member limit.

But is the user limit only for the free version? As I read that support email it was simply a limit on the size of Slack teams across the board.

You appear to have not read the article. The very first complaint is about the 10k message limit warnings. The author then complains "Slack would aggressively archive messages, sometimes only minutes after they were sent." He's lucky the messages even went through. He asked Slack for guarantees, after the fact, on the free plan with no intention of paying Slack's rates. Even the user limit problem is silly. It's called a team and marketed for internal use, not as something you 're-sell' or offer customers. It's obvious that putting your users on a single Slack team is not going to scale to tens of thousands of people, as soon as you start using Slack. My point here is that the author did not do his homework before he moved his thousands of users to Slack, and your point falls squarely under this lack of effort.

His point, which you have missed, is that although the archive thing was a problem, it may been their own fault. However, the number of users allowed was not, plus paying for the service wouldn't change that the cap exists.

My point, which you have missed, is that the author should have uncovered this cap before moving his community. It was clearly on sketchy ground before he did it. You can't say anything about what paying would have done, because he had no intention to pay. And if he had paid the 0.5 million, I'd be willing to bet that Slack would attend to his needs. But none of that happened, so it's a straw man.

Please share your method of uncovering, in advance, undocumented limits inherent in software; it's desperately needed.

The guy left a free trial for another free trial; if he's at fault we're all at fault every time we change our go-to software. The lesson might be that "there be dragons" - you should guess that any "better" program or SaaS out there is less that half of what it says once unknown limits have been discovered.

Customer: Hello vendor, we're a customer with tens of thousands of active users and no intention to pay. How many users can you support in your free tier? How do you handle situations with high message volumes?

You should engage with the vendor. Perhaps there are intangible benefits to the vendor for you to use them even at no cost (PR, testing opportunity, etc)

Generally speaking, if you are dependent on a free service to do your business, you are fucked. A friend is a policy consultant who relied on Google Reader to be his knowledge repository. He bills the equivalent of $800/hr and was nearly paralyzed as it went away.

It's called "due diligence", and people do it all the time.

He didn't change his own personal go-to software, we're not talking about a trial of a video game here. He changed the software for thousands of his users. He put thousands of people on a free trial for something that was not obviously going to work.

You do have the option to investigate before you make that kind of move. If you choose not to exercise it, you don't have that much ground to stand on when things don't work out.

The due diligence in this case would have been researching the user limits which (as others have pointed out) were not published or advertised anywhere.

There's a reason it's called "diligence", because it typically involves trying. Personally, I don't count reading a company's ad copy on their own web page as being even remotely diligent or doing much research. Normally 'due diligence' involves talking to the party you intend to engage with, as well as talking to others who have experience with that party. The author didn't mention any of that.

Other users here also pointed out that there is a known specific API error message for the user limit. That kind of thing could be uncovered with a little diligence. Author could also have setup a fake team and tried to add many users before putting 8k real users on the team and just hoping.

He did finally start talking directly to Slack only after he started having trouble, and they responded and disclosed the existence of a team size limit. This obviously could have happened before hitting the limit.

The author expressed incredulity at what would be a $500k price tag, and yet completely fails to see why that is a massive glaring red flag. That alone should have been enough signal that his plan was skating on thin ice, but instead he drove right past all the warning signs and then blamed Slack for it.

Trying a huge number of users? How without migrating?

He could have asked innumerable questions all of which contradicted the description of what he was getting. He couldn't have known which was the right question. I very rarely query in person before a purchase; I did recently and was given a flatly wrong answer on one question, and then a very positive answer that wasn't logically coherent (strongly suggesting a no, in truth) on a second question. I'm buying anyway, but unless you can phone a corporate head, querying customer support for arcane technical information is rarely a great way to get the right answer, in my experience (sorry to say.) UNLESS you already have a proven fail, of course - which he did.

If it were my program there'd be an error message in there no matter what the upper limit was; I assume others are as competent.

I also don't follow your logic re the high price tag somehow logically entailing a secret limit on the free product - unless you're implying that it's a trap, a way of phishing for phools. (In my country, an illegal bait and switch, actually.) That's something that doesn't work too well when you're peddling to corporations, the pool is small and word gets around too fast.

> I very rarely query in person before a purchase

Yeah me too, for things I buy for myself. But it's absolutely the norm for software purchases of $500k. That's what everyone does, it's extremely common practice for any org purchase of software for over 100 people.

If the author were actually looking to spend $500k, he definitely would have called first and done a bunch of research. Nobody spends that much without talking to someone. The only reason he didn't have that dialogue is because he thought he'd get the whole thing -- apparently a $500k value -- for free.

That's what I mean about the price tag being a signal. It should have signaled a phone call, at the very least.

"There's also no limit on how many people you can add to your team on Slack."

-- The Slack screenshot in the article.

> It's called a team and marketed for internal use, not as something you 're-sell' or offer customers.

Do you have a source for that information? One of the roles of Slack[0] is named "Member" not "Coworker".

> the author should have uncovered this cap before moving his community.

He tried: Slack said there was no limit, yet there was. Even Slack themselves mention starting with a "pilot team"[1] to demo; which wouldn't have discovered the limit either. How would you discover it?

[0] https://get.slack.help/hc/en-us/articles/201314026-Roles-and... [1] https://get.slack.help/hc/en-us/articles/217626298-Tips-for-...

How about "Slack for Teams is a single workspace for your small- to medium-sized company or team."? https://limnu.slack.com/pricing

But your question presumes that the word "team" isn't enough, and that the implied team size that comes with a 10k message limit also isn't enough. Why?

If the authors expectations were higher than they ought to have been, that was because the Slack marketing team set them so high.

I think he's being a little bit to hard on Slack. He was really stretching a free trial offer beyond its limit. If he was a paying customer then I might have cut him some slack.

What I understand is that author did a trial and hit technical limitations in the desktop and mobile applications, I think that paying extra would not had help. Probably the slack developers did not tested with such a large number of users, it reminds me when I worked on a rss feed application and we were testing with 40-50 popular feeds, then a client shows up with more then 1000 rss feeds , I end up grabbing his feeds and testing with all of those and optimize the application(We did not expect someone would had so many feeds).

Reply on news.ycombinator.com