Should I build my product In-House or Outsource it?

One of the main challenges of starting a products based company is how do you build your product? This is especially true of web based companies, whose product consists of mainly a web site and very little more. For many companies, their web site is their lifeblood. Unless you’re fortunate to have one or more technical founders, you’ll quickly be faced with this simple question:

Do we hack out a prototype somehow, find a developer or outsource the development? All have pros and cons ( only some of which are listed below ):

1. Create the prototype yourself

  • Cheap – this only takes up the time of your and your founders.
  • Total Control Over Implementation – Since you’re building it, you have the kind of fine grained control over everything.
  • Flexibility – You won’t need to commit to something, either cash, equity or involving other people, upfront. You can make decisions as needed.


  • Slow – You’re not technical. Depending on the level of complexity and difficulty, it might not be the most efficient use of your time.
  • Un-knowledgeable – Since it’s just you and your partners, you might not be making the best choices.

2. Find and hire one or more developers

  • Implementation Speed – Developers working full time will be much more efficient for you and your product since they’ll be dedicated to your company.
  • Technical Expertise – Bringing expertise in-house is the best way to foster communication and feedback when building a product.


  • Money – Unless you have cash to pay, the pool of developers willing to work for equity is small.
  • Equity – It’s not unheard of for a developer to look at a web based company, see that he’s asked to build the entire product and ask for a large chunk of equity as compensation.
  • Access – Good developers are tough to find.
  • Communication – Hiring a technical employee early on can sometimes result in a founder developer gap.
  • Need – If you just need a prototype or initial version of your product built, hiring a staff might be premature. While your team is trying to iterate and perform Customer Developer, your tech staff will be idle. And there’s nothing idle developers like to do more than think of new features to implement.
  • Lack of Knowledge – Building out a technical team when you’re not technical is fairly difficult.

3. Outsourcing

  • Capacity – development companies have people waiting to build your product.
  • Known Entity – You only need to guide the development of the product, they take care of finding developers, development process, etc..
  • Delayed Commitment – You don’t need to worry about hiring on people too early.
  • Cost – Outsourcing tends to be cheaper than hiring on developers and building your product internally.


  • Cost – Most development shops work on a cash basis. There are a few that take equity, but a ) they’re rare and b ) you’re making a significant decision about your company pretty early on. If the relationship sours for some reason, severing it could become pretty hairy.
  • Lack Of Communication – Typically there is a very “over the wall” approach to development where you specify requirements upfront and they give you what you specify. The type of day-to-day communication that takes place when developing a product is limited when the development staff is outside of the actual company.
  • Lack of aligned interests – While there is a desire to perform good work, development shops are not necessarily looking at the long-term outlook for your product. They may make certain concessions or decisions that could hinder the flexibility of your application

There is also a hybrid variant of #2 and #3 above that I’ll call a development partner. A development partner is an consulting company that works very closely with you, similar to an internal development staff. They are looking at a long term relationship and are more likely to take a craftsman approach your product development. Thus, they typically take a vested interested in ensuring whatever they build will be able to evolve with the company. Lastly, they are more likely to take reduced rates, be open to a debt-to-equity relationship with you and your company or some other more flexible compensation setup.  

So given all of that, which should you choose? Well, like most decisions, it depends:

  • #1, from my point of view, is out. If you’re not someone who can get up to speed VERY quickly and hack out a rough prototype, it’s simply not worth your time and effort to make the attempt. Unless, of course, it’s your very, very last option. Options #2 & #3 would have to not be possible for you to go this route.
  • #2 is also difficult, though not impossible. It’s only a viable route if you have to cash to hire someone and you can keep them busy enough with relevant work, not just aimlessly spinning their wheels. Without the cash, you’re very close to being DOA. Most of the technically inclined engineers who would have the itch to work at a start for equity are already working on their own idea.
  • #3 is a viable option if the relationship is properly managed and the product itself is fairly well thought out ahead of time. However, it should be known that, especially early in a products history, it will fluctuate. Having a outsourced relationship that can withstand those fluctuations is critical. You should place a premium on outsourced companies where the speed of feedback and communication can be the quickest.

In the end, I think there are two preferred routes: either find a development partner or hire a technical advisor or CTO-type person to manage an outsourced, development shop relationship. For the former, the partner you choose should be flexible enough to work in small bursts for you, as needed. In the case of the latter, this keeps your staff and employee commitments down. The latter option also allows you at least one person that can act as a liaison between the purely business founders and the technology team, whether they’re internal or external. You can also use them to bridge from the development shop into a internal team setup when the need arises.