Look what I found: Slack's free tier pricing page explicitly states "There's no limit on how many people you can add to your team on Slack." https://twitter.com/FreeCodeCamp/status/612758062214950912
452 karma · joined October 1, 2011
I want to point out that communities are increasingly using Slack, and many of them are also in the thousands of users. Slack does nothing to discourage this, aside from posting warnings about archiving messages.
The real problem is that they have an undocumented user limit. Like I said, I'm pretty sure we're the first community to hit this limit.
Big online courses, for example, routinely draw 100,000s of students, and might make the same mistake we did (Harvard's CS50 class did).
Slack may be able to fix its sluggishness for these other communities, and someone might build integrations that routinely export then delete messages so as to stay below the 10,000 message limit and remove the warnings. But it's too late for us. We can't pause our community growth while we wait for Slack to engineer around their undisclosed user limit. So we have no alternative but to switch.
The main reason I wrote this post is to provide a cautionary tale to other open-membership organizations who are considering using Slack. Slack doesn't seem to be intended to do this! Please don't do this!
To take the OP's points one-by-one:
- Hackathons are worth the commitment. They're a fast, efficient way to try out 1) new frameworks and APIs, 2) new employees/cofounders, 3) new ideas.
- Hackathons only exclude people with "lives" who don't choose to make the event a priority. Hackathons filter out timid and less motivated people (and those two attributes are related) and you're generally left with pragmatic people who will make it through the weekend.
- The OP is right. The inconvenience isn't evenly distributed. Life isn't fair.
- Hackathons are only as unhealthy as you make them. Gardening can also be quite unhealthy if you don't wear sunscreen.
- Competition is a positive force, and the extrinsic motivation of judgement and a deadline are real, and good for the hack you produce.
- Since this is a competition, you can't work on a preexisting product any more than you could start a marathon a kilometers up the road.
- They're not just toys. Take a look at POWr.io and Zaarly, both of which came out of hackathons. There are many others, and if anyone knows of some of the top of their head, please reply with them.
I think it's great that people are coming together to help code on your gardening project. Hackathons may not be right for you, but they are definitely right for me and the dozens of ambitious people I've coded with at hackathons over the years.
Anyway, the problem with Fountain is you still have to ask a question. And if you can formulate a good question to begin with, Google (which is fast and free) might very well provide a better answer than some random domain expert willing to answer random questions for small amounts of money.
We have a project-oriented full-stack JS curriculum at FreeCodeCamp, but if you're looking for a Rails curriculum, check out OdinProject. Erik's curated the best rails resources. And I agree 100% with what Malcolm Diggs said. Build, build, build!
The $35k/year/worker support staff would seem to be the only capital-intensive aspect of the business.
Instead of intentionally walking around blindfolded in preparation for a loss of vision that will hopefully never occur, I could thank my lucky stars that my eyes work and focus on using them to the fullest.
How would you feel about: "Macs combine the user-friendliness of Windows with the Unix environment necessary to run most tools and frameworks."
9 years later, when you were looking for a cofounder, you decided to go with a technical cofounder.
You can talk all you want, but at the end of the day, you chose to bring on a second technical cofounder (the first being yourself) over the business cofounder that you are recommending the OP seek out.
N.b. by technical cofounder, I don't necessarily mean someone with a PhD in Computer Vision. I mean someone who can productively write API integrations and use whatever tools are needed (e.g. Rails, Meteor, Xcode) to build the product.
Having specialization early on was a mistake. It was a difficult situation, and it wasn't entirely his fault that there was, for long stretches of time, little for him to do.
A startup cycle goes something like this: initial theory -> MVP -> validation of theory using MVP -> iterating to product-market fit -> scale
Even in that highly oversimplified flow, there are a lot of shifts from "product mode" to "development mode". Most of these steps must happen sequentially. If only half of the team is fully engaged in any given step, you get a lot of slack.
There's a joke that first startups should hire a bunch of developers to build the product. Then they should fire the developers and hire a bunch of salespeople to sell the product.
Which begs the question - why not just hire developers who can sell, and avoid paying all that unemployment?
Larger organizations can get away with having specialists onboard. Smaller organizations (2-3 people) can't afford this luxury.
Your advice would hold for a later stage startup, but it is unreasonable advice for an early stage startup.
On the face of it, this advice seems reasonable. But this advice will result in precisely the asymmetry to OP is worried about. If you have a technology product, I strongly discourage you from taking on a non-technical cofounder.
I made a huge mistake co-founding a company with someone whom I thought had a skill set that would compliment mine. He was, of course, a non-technical. While I coded for 90 hours a week trying to build an MVP, he did thought experiments, worried about competitors, and fretted about the color of our logo. In short, he did very little to move the product forward other than arbitrarily tweaking design specifications (before we had MVP and were even able to A/B test or validate with users). It was an extremely counterproductive and demoralizing experience.
This may sound like an edge case, but I meet people all the time whose startups failed because the team couldn't get along. This is usually caused by one person feeling like they're doing all the work. And that's usually because one person IS doing all the work - the other person is a non-technical cofounder, and can't do much meaningful work, only look busy by trying to get twitter followers, having lunch meetings with reporters, and doing competitor analysis - all work that is meaningless if you don't have an MVP you can use to validate and iterate toward product-market fit.
My advice is simple: find a technical cofounder who also has the confidence to pitch. Find a technical cofounder who can help validate an MVP and iterate it to product-market fit. Find a technical cofounder who isn't daunted by needing to pick up new skills. This is a startup. You're looking for generalists, not specialists. Whether someone can code is a good litmus test for whether they are serious about doing tech startups, or merely dabbling.
Also, how would you feel as a journalist if the investigative piece you'd spent the last three weeks on was ultimately riddled with "buy it now"s?
But it's clearly not enough to say "the US isn't as bad as everywhere else" if everywhere else is merely drifting toward consolidation more slowly.