TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Ask HN: Building Startups: A few big ones, or many smaller ones?

3 pointsby dryicerxalmost 16 years ago
What are the ups and downs of doing large start-ups, vs smaller start-ups? Is it better to start out with a few smaller ones and then try to tackle larger start-ups? What are you experiences.<p>This is just a general blanket question trying to get the opinions.<p>When I say Small Startup, I mean something that requires less than 5000 man hours to Public Beta.

5 comments

pgalmost 16 years ago
You can't determine ahead of time what the size will be, because projects grow. Most huge companies started out as something much smaller.
chaosprophetalmost 16 years ago
If you measure the size of a startup by time to public beta, then you are making a fundamental mistake. The thing is, before you go public, you can spend as much or as little time as you want, but once you are public and people actually star using your stuff, you will have to continuously iterate and refine your stuff. So I would say the majority of the work comes AFTER you go public, and hence time to public beta should not be your criteria for determining the size.<p>Having said that, it is always better to do stuff one thing at a time. It ensures that a. you don't get swamped, and b. your full attention goes towards the one thing you're working on.
inertealmost 16 years ago
How much time it took you to think about this question? 1 hour? A day if we count an event that happened today? A year, since you've decided to follow a certain path? A whole life maybe, if you think everything you did and everything you are lead to this question?<p>The same questions can be applied to your startup(s). Doesn't matter if you already put, or is planning to put, 5, 50, 500 or 5000 hours.<p>A 5 hour project can become a lifetime of adventure. It isn't about how much time you give, but how. An hour of a plumber is cheaper than an hour of a lawyer.<p>Don't get me wrong, hard work does pay off. But your output (the result of your work), is NOT measured by your clients perception of how much time you spent on it.<p>I've tried to search for a joke that would explain my point but couldn't find it to copy and paste. It goes like this:<p>A company is having problem with a machine. They call someone who asks for 100 dollars and spend one hour trying to solve its problem, but is doesn't go well. Then they call someone who asks for 200 and spend three hours trying to fix the machine, but is also doesn't work. Then they call someone who asks for 50000 dollars and spend five minutes, just to flip four switches, but who got the machine working.<p>Angry, the company demands an explanation for the expensive bill, and receives this reply:<p>Time on the machine: $10<p>Knowing what switch to flip: 49990<p>And that's what you want to work on. Not on something that gives return on the time you spent on (altough it doesn't matter, it'll probably be high) but on what your knowledge is most valued at.
credoalmost 16 years ago
my answer is neither. ymmv<p>Instead of a "a few smaller ones" or "larger start-ups", imo starting with just <i>one</i> startup would be a better idea.<p>It is easier to do a good job on one startup if you're focusing solely on that startup (especially since your definition of a small startup includes startups that could take a few thousand man-hours).
评论 #701244 未加载
staunchalmost 16 years ago
I would limit yourself to 3-4 months for a beta at the outside. I don't know about you, but I have trouble working on something for longer than that without getting some real feedback. That doesn't mean you have to do something small. The first version of Google could have been done in 3-4 months.<p>I think it's better to decide what you think will be most successful, and then figure out how to release a version of that in a few months. I don't think it's wise to shy away from hard problems. Better to figure out how to solve them intelligently, so they're not so painful.