I have also thought of this, and I have fortunately seen a lot of startup developers come and go, learning a few lessons from each.
I have some guiding principals on what I think would work for a developer that will actually do well opposed to hanging on a by a thread for few years as some lame game company nobody that cares about.
Principal 1:
It really is all about the people who work at your company. Good developers (whatever their role) are very hard to find. You can hire 2 dozen programmers in 6 months to a year, but out of that batch you might only get one or two good ones. The same goes with artists, designers, etc… Good people are your most important asset, and the most difficult asset to acquire. Blizzard has spent years being picky and holding on to the very best they can. That is the ‘magic’ they have, that is why they can keep coming out with blockbuster games.
Be careful how you evaluate people as well. Maybe that artist who is grumpy and thinks all the art direction sucks, is actually right. Maybe Mr. Positive thinking who thinks it is all good is just dead weight. People may like him better, management may be thrilled at what he has to say, but unless he speaks objectively and truly, he is a liability, not an asset. Similarly people who have giant egos are usually a bad fit in any team. Even if they are really good at their job, they may cause other good people to be not-so-good.
Principal 2:
Know your limits. Do not over promise to a publisher. Absolutely do not plan on “overtime” or “crunch” time as part of your estimate of when work is going to be done. IE: If you think something is going to take 400 man hours, do not say “It would take 10 weeks, but if we work 60 hours a week, we can do it in about 6 weeks.” I know this is a great temptation by employers, because you generally think you get stuff done faster and since your employees are salaried, you do not pay for the extra 20 hours a week.
The obvious problems, which so many managers overlook are: Burnout, lower quality work, less productivity even with the extra time, and the real possibility of something going wrong which will crank up the hours a week even more. Crunch time should be reserved for unplanned events.
The most common causes for crunch time, even if you do not plan a schedule around it, are: Poor planning, feature creep, and over-commitment. There is not much you can do about the first one, that comes from experience. Just be sure and learn from your mistakes. If in doubt, double your estimate. Its better to be ahead of schedule then behind. You have little control over how productive your team is, but you can control the schedule they are trying to stick to.
Principal 3:
Team cohesion. Even if you have a team of developers, where each individual member is of high quality, there are still a lot of problems with people working together. Maybe Programmer Bob isn’t good at AI and would be better working on a rendering engine. Maybe your texture artist is good, but is really a great animator. You need to know where people best fit. Just because they are applying for job X, doesn’t mean thats where there best at. You may find that programmer Bob may make a fantastic designer and not be a programmer at all.
There is also the tools everyone will need. You might think a computer with the latest 3d studio max might be all that a artist needs, but learn that there are two dozen other things that will help them do their job better.
Your programmers might want to write their own engine. This might be good or really bad. If you go with middle-ware, they will need several months just to tinker with it. You can’t just buy the license for the code and expect your code team to hit the ground running.
The final step for this principal is to make a minor game with very little pressure. This will help you find who is good for what, build your cooperate culture, and turn your development team into a well oiled machine instead of a collection of parts.
This, of course, will cost more money to do, but in the long run I am sure it will yield a much better company then if someone with a few million in the bank hires a bunch of people and expect them to crank out a good quality game in 1 to 2 years.