Internal vs Outsourced Software Development

One of the core challenges with building a web-based company is developing the software. Naturally, there are many debates between developing the software with an internal engineering team vs outsourcing the development to a firm, onshore or offshore. Let’s look at a few issues to consider:

  • Is the product central to the company’s success or is good enough OK?
  • Do the founders or CTO have experience managing an internal or outsourced development team? An outsourced team is generally considered more difficult to manage and management intensive.
  • What type of financial resources are available in the near term and longer term? One-time projects might be more cost effective when outsourced if scope is sufficiently defined and the platform is a known technology (e.g. writing a simple iPhone app).
  • How fast and iterative are the product changes? I’ve generally found internal teams faster at iterating when compared to an outsourced firm that is juggling multiple projects.
  • How accessible is local software development talent? The size of the city and quality of nearby engineering schools can be a factor in finding good internal software engineers.

In my experience, I’ve had the most luck with internal software development teams as our product is our core competency. I have heard stories of software companies having success with completely outsourced software development, even offshore work, but the number of failures I’ve heard about significantly outweighs the wins. My advice is to seriously consider an internal team, even if on the surface it appears more expensive.

4 thoughts on “Internal vs Outsourced Software Development

  1. Based on prior experience, I would reduce your list of questions down to just one.

    * Do you need the offshore team to innovate?

    I’ve worked specifically with offshore teams in both India and China, and first challenge is always recruiting senior managers/mentors within those regions. This usually leads to spending a lot of money on travel and eventually sending senior resources to live in those locations (including additional salary and covering all living expenses). When these resources come under pressure to ship product, they will often take on too much of the work due to quality/deadline issues. For the FTE’s in these locations, large raises are the norm to retain talent — or churn becomes higher than the expected 20-30% (churn was on the lower end of this in Shanghai and on the much higher end of this in Bangalore).

    In facing these challenges, I wondered how other companies (such as Microsoft) were operating in this same environment. While recruiting new developers while in Shanghai, I had an opportunity to talk with many developers from some of these large companies. What I learned in the case of Microsoft is that all product innovation was being done in Redmond, and the teams in China were a support structure. They handled issues with the builds, bugs that came up, set up of environments, etc.

    I found the same to be true for what worked well for us — we had several teams that focused solely on bug fixes within a 4GL language. This worked really well. For new features, however, progress was painfully slow, at times 20x total time with 5x the resources of what we could do on shore.

    I’ve heard of success stories in Eastern Europe — and that this is a far better place to set up over the alternatives. But if the domain experts are not sitting with the developers, the product will suffer.

    1. Thanks Brian. You have way more experience than most people that I talk to about this. Thanks for clarifying and adding a different perspective (my only perspective is doing the engineering in-house).

      1. No problem — I’d actually be interested if anyone reading this has an offshore success story to share. I always seem to hear these successes second hand, so it is difficult to assess if they were really successful, or simply had the appearance of success because of the perceived cost savings.

        There are definately some sharp developers in China — but for every one of those, there are 30 average ones. And while the same might be said for the US market, try figuring out which is which in an interview that requires a translator.

        Even though English is pervasive in the popular off-shore markets, it can’t be discounted as an issue. The ability to speak English is often orders of magnitude higher than the ability to listen and discern what is said. Differences in cultures have to be learned as well.. I’m currently reading Outliers, and there is a section in the book dedicated to the correltion of air disasters and the pilots’ home country. That chapter could have easily been written about past software projects I’ve seen go off course (referred to in the book as the “power distance index” of a given culture). Imagine a team of developers that may see a problem upcoming in a project, but dare not speak up because they are “below” the managers on the perceived food chain. And then imagine that all QA are perceived to be the lowest on the food chain — so now imagine a QA team that dare not overly question a development team member.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.