How many programmers should a startup have?


You've got an early software project, it's reasonably popular. There's no known limit to the product's potential size or usefulness. You've just gotten funding.
How many programmers do you hire?


asked Oct 22 '09 at 14:14
136 points
  • You should also explain how much funding you got so we can give you rough estimate. – Jpartogi 14 years ago
  • 42? How can you possibly expect a sensible answer to this question with the details supplied? – Ryan 12 years ago

9 Answers


As few as possible. Only hire when you're hurting.

answered Oct 23 '09 at 06:05
171 points


There's not enough information to answer your question, but I'll provide some parameters.

  1. It really depends on how much funding you got. It's a really different approach when you get the proverbial $5M VC from an early stage $100K friends and family.
  2. If you got plenty of money, you don't need to figure this out, hire a CTO and he'll know the right answer :-).
  3. OK, so let's say you hired me as the CTO :-). I'd probably hire no more than 5 developers initially. Better, I'd try to bring in people/a team that I've worked with before.

I think that's really the answer you're looking for. Like everything else in life, you can't build things too fast, even if you have tons of resources, or they'll fall apart. Hire a CTO. The CTO hires 5 senior people who get to define the next generation of the product, get familiar with it and with each other. The CTO and his people can in turn hire a 15 more people and break them into teams, and so on.

One other thing that you need to realize is that a team of 5-6 developers can a lot in a new product. At the end of the year, they'd put in 5-6 man years into the product :-).

answered Oct 22 '09 at 14:28
1,833 points


Right, too little information. If this thing is still early and small, and your investors aren't forcing you to hire more, I feel like a great number is 3. 1 designer, 1 developer, and 1 guy who helps fall in between. Maybe he does some design, maybe more development. But can help both other folks. 37signals also shares this same advice and built basecamp originally with this number.

answered Oct 22 '09 at 16:25
Nathan Kontny
1,865 points
  • My opinion, 1 guy that helps in between would be better as the marketing guy. Hey you need your product to be sold right? And we must admit, technical people are really bad in marketing even their own product. – Jpartogi 14 years ago
  • I disagree on "technical people are really bad in marketing". What's true is that most technical founders haven't spent much time doing or practicing marketing. But when they do, they are often the best sales people. Paul Graham has an excellent essay of how he was doing sales at Via Web. He had no idea what he was doing to start with, but that helped him. He just told the truth. Not a "marketing" version of the truth, and he kicked ass. – Nathan Kontny 14 years ago
  • @NathanI would say that highly focused people, like developers, are not so great at marketing to other groups of focused people. Thats where a marketer comes in. Although I agree with your original answer, I feel like a good 4th person would be a general purpose marketer who can look at your product from a different perspective. – Rob Allen 14 years ago
  • I am not saying people who are great at marketing are a bad resource. Depending on where this project is at, early money is best spent on building awesome features. Look at the awesome stuff Y combinator teams build. Generally 2/3 guys. Zero marketing guys in these groups until they get a significant round of capital to start getting sales and marketing people involved. Try to do any marketing yourself first as a founder. Feel the pain of doing those jobs before going out and hiring talent here. Also read Joel Building stuff is often the best marketing technique. – Nathan Kontny 14 years ago
  • +1 - Agreed. I very much believe in the 37signals / getting real / rework mindset. Even if there was ton of funding it just wouldn't make sense to hire a ton of people for no reason. Keep the team small - don't just burn money. You'll know when you need to hire more. – Ryan Doom 12 years ago


1 but an awesome 1

s/he'll help you to figure out if you need more

answered Jan 10 '12 at 10:22
Henry Viii
11 points


As was mentioned previously, hire as few people as possible. The more employees you have, the more "overhead" (read hassle) you will have to go through because no matter how good the CTO is, you will still have to deal with payroll, holidays, sickness, slacking and other interesting problems that occur when people work in groups.

answered Oct 23 '09 at 07:46
146 points


From my own experience as a software developer, one rock star programmer is worth ten. You'd better get a team of the 2 greatest programmers you can find than go and hire 10 unexperienced ones. They'll get more done in the same time and do it better.

I would add that the choice of technologies is as much important. As a startup, you probably want to go for open source and languages that offer high productivity. You shouldn't worry too much about performance or scaling issues at this point. Focus on what you're good at and let cloud providers do the heavy lifting.

Talking from my own experience though, this might not hold true in all cases.

answered Oct 23 '09 at 09:12
Olivier Lalonde
2,753 points


Hire one really strong, seasoned developer (or ideally have her/him on the founding team and pay less), and add 2 more. Pick a fast dev platform, and race away in an agile mode. Keep management issues to a minimum and get product built. If you can afford it at all, bring in a virtual CTO/advisor who can help set up your overall technical direction right so that you don't have to rip out all your code later, but can actually refactor it all :)

Also, demand automated testing at the unit, functional, integration and UI level, and you'll get a ton done very fast.

answered Oct 23 '09 at 21:26
Manuel M
263 points


Depends on the product, depends on the requirements, depends on the legacy code. 1 KLoC or 50KLoC code or not code at all?

If you are just starting feel free to go up to 5, if it's legacy code I don't see a point more than 3 since you can't let them just dive into the code. So get 3 first train them, when they are confident about the code, application and the vision then you can hire 6 more if you really really need it. But it's darn rare that you'll need 10 developers in that early, and it'll pain to manage.

answered Oct 23 '09 at 05:29
The Dictator
2,305 points


I would recommend the following strategy:

  1. Hire the best engineers you can afford, but only ones that have "been there, done that". It is true that 3 or 4 rock stars will get you more bang for buck than a group of 10 or 20 mid level or mediocre senior level engineers. You will want engineers that are passionate about the particular technology or space you are in. These are the kind of engineers that will strive to deliver the best possible code/design.
  2. "Been there, Done that." - Engineers who have already solved the problems you are about to face won't waste time learning how to solve the same issue, thus your development will go much quicker and they can share experience for business decisions.
  3. Make sure the product/service is built right from the very beginning. Short cuts taken early on always bite you in a critical moment down the road. What will happen is that all the engineering debt piled up from taking a year of short cuts will cause you to not be able to execute what should be a simple refactoring in a crucial time for that whale of a customer. So, while it might seem wasteful to spend a day discussing some design pattern or technology, that discussion and the implementation that stem from it will pay you big dividends in the long term.
  4. Hire a really good QA Engineer so that you have established testing procedures at all 7 levels right from the beginning. This is also a best practice that will save you time and money in the long term.
  5. I agree that a group of 5 is a nice size group, however, this number really depends on how much work there is to do, how big the product/service is in terms of functionality, features, scope, etc. and how much specialization you need to begin with. You may not need that many generalists, but you may need specialization in release management, scalability, database, User Interaction, etc. depending on what your product/service is. If you can afford it, I would recommend that your rock stars each have a specific specialization. This way if you need to expand the team further you have engineering group team leads already in place.
answered Oct 23 '09 at 11:52
156 points

Your Answer

  • Bold
  • Italic
  • • Bullets
  • 1. Numbers
  • Quote
Not the answer you're looking for? Ask your own question or browse other questions in these topics: