As you go about building your company’s product, you will come to the decision about whether to develop your product in-house or outsource it.
There are advantages and disadvantages to choosing to develop your software in-house, and you should carefully consider your resources, your aims, and what you’ll ultimately need from your software and from your developers.
Advantages of an in-house team
Customization. When the entirety of the development happens within your own company, you have control over the product you’re getting. Your development team probably has a desk in the same area as you and their full-time assigned role is to work with you to produce the best product possible.
Communication. Due to the likely physical proximity of an in-house developer, things can be iterated much more quickly. You can bring up bugs, issues, and improvements in a matter of seconds and have an immediate and useful conversation.
Understanding. Assuming you’ve got a good company culture going, your team is just that—your team. You are all working toward a common goal and everyone has vested interests beyond a paycheck.
Disadvantages of an in-house team
There are some serious drawbacks to take into consideration when choosing to develop your product in-house.
Expertise limits. The product you’re designing might very well be beyond the scope of your in-house development team or it might be in an area that they aren’t well versed in. Putting a project that is well beyond the expertise of your team can result in huge delays and greater expenditures.
Resource limits. Being in a startup entails a lot of late nights, moments of panic, and a sense of being overworked 24/7. If your product or products are particularly complicated, your developer team might be better suited focusing on a few projects while others are MVP produced by outside developers.
So you’ve got this magical idea to build a great piece of software and you want to do it in-house. Maybe you have some experience or maybe you have next to none. Maybe you’ve developed software for another startup or maybe within an enterprise.
Before doing anything, you should plan on doing some reading. You’re going to want to learn how today’s startups manage their work and make certain that it aligns with your product vision. This will help to establish common language and ensure that you understand enough to keep your project on track.
Get to know Agile Software Development, a set of principals that were created for the purpose of developing software. However, these principals have permeated throughout all of startup culture, from marketing to product development. The idea is that you learn to follow the principles and refer to them when making decisions.
Building a team
You may have enough knowledge and experience to hire and manage a developer or team of developers yourself. If not, you’ll need to find someone who can build the first iteration of your product, figure out how to release it, and take the lead on all technical decisions.
If you’re building an iPhone app, you may only need to cover a single technology discipline. If you need someone to cover many technologies—such as apps, databases, and server infrastructure—you’ll want to look for someone who can wrangle all these things. In a startup, this is not an administrator or manager, but someone who can switch from coach to player at any given time.
When you’re hiring this person, look for someone who has done something similar before. Ask them to tell their story. Find out their greatest failures, challenges, and have them explain how they overcame them. This person should be communicative, tenacious, approachable, and give you enough information to demonstrate problem-solving skills. Ultimately, they need to convince you they can deliver and agree to be accountable.
If you are hiring additional developers, you’ll want those who are more interested in developing software rather than big picture types. This does not mean your developers are specialized or can’t think about the big picture. Ideally, every engineer you hire, particularly early on, should eagerly jump in wherever they are needed. Anyone that is too specialized or says “I don’t do that” is not someone you want around when you’re starting out. More specialized developers are usually a better fit for larger organizations that can afford that level of specialization.
You may be tempted to think that hiring many people as fast as possible is a good thing, no matter how much money you have. It's not. A good rule of thumb for myself is that I should only hire additional engineers if the ones I already have are working relatively efficiently, I need another skill set, or I’m building a new team. Otherwise, communication and throughput can breakdown. The team should help you decide when the time is right. They should also have as much say in each hiring decision as anyone else.
At some point, you’ll find yourself with someone who turns out not to be a good fit for your team. If they are definitely not working out, you’ll want to replace them quickly. You’ll regret it if you wait too long to do so. Giving a new developer a small project to complete right out of the gate can help identify issues early on.