5 reasons to avoid outsourcing your product development

I'm not just a programmer - I am a machine!
I’m not just a programmer – I am a machine!

A familiar problem that I frequently encounter when engaging with very early stage startups is the lack of a product, and a lack of a technical co-founder who can also build that product. Faced with such a showstopper, the budding entrepreneur will frequently consider outsourcing or offshoring to overcome this hurdle. While this approach can work in theory, more often than not it will prove to be a costly mistake.

Here are 5 reasons why you shouldn’t consider outsourcing the build of your minimum viable product (MVP):

1. You don’t know what your customers want

You have a good idea, your friends and family have told it’s good, some of them have even offered to put some money up front to help pay for the outsourced development. It’s tempting to think then that the only thing holding you back is having that product built.

The problem is, you are a first year student of lean startup principles. You are well aware that the purpose of an MVP is to test your assumptions about what your customers want. You also know that despite your extreme confidence in your product, that you probably haven’t quite hit on a winning formula. You know that you will have to run multiple experiments, test, refine and shape your product to produce the ultimate solution. You soon begin to realise that the initial $2000 quote you had from that development house the other side of the world is going to begin to bloom and then explode. Worse than that, you have to fit your spending into their available schedule. Not only is it becoming very expensive, it is taking forever to get results.

The whole point of an MVP is to be able to iterate many times until you reach something that works well with your customers. The only way of doing this in a fast and cost-effective manner is to do it in-house.

In my experience, fledgling startups that go down the outsourcing route end up spending many times more than they originally predicted, and end up with a product that is considerably different from their dream, and that no-one is interested in.

2. If you build it, they will come?

We can’t really blame Kevin Costner for this one – it was a made up story involving ghostly baseball stars, hardly something you are likely to emulate in your business plan. Despite that, the myth persists that the only thing stopping the budding entrepreneur from becoming wealthy is a working product. Unfortunately, the truth is anything but that.

If you build it, they might come
If you build it, they might come

There are virtual graveyards full of dead tech startups who had some fairly smart products backed by teams of technical geniuses, who failed to secure enough customers to take their idea and turn it into a successful business. They failed to achieve sufficient traction.

Building a business is hard, building a product isn’t anywhere near as difficult, as all outsourcing companies know. From day 1, you need a coherent plan about how you are going to attract interest in what you do, and turn those early interests into paying customers. Don’t be thinking you can do this by working social media channels and attracting enough traffic that you’ll get rich from selling advertising space. You won’t – those days where that approach worked are long gone and there’s already too many other companies out there doing something similar to you. If you think there isn’t, you haven’t looked hard enough.

A coherent strategy that starts to be implemented from day 1 about how to attract customers is essential, and should attract as much time, effort and money as the product build. I examine the need to do this in The Lean Startup Myth.

3. You will only get what you ask for (if you are lucky)

As with any line of work or trade, there are good companies out there and bad ones. Let’s assume you’ve done your research, checked references and located a company that is reputable and will do a good job.

The best you can hope for is that they do what you ask for – nothing more and nothing less. This might sound like a good thing, and it is, if, and only if, you have experience in writing software specifications. Even simple apps and websites have a great degree of complexity. For example, what does a valid telephone number look like?

  • 01234 567 890
  • (01234) 567 890
  • (01234)567-890
  • +44 1234 567890
  • +44(0) 1234567890
  • etc, etc

All the above examples are different ways a user might type in their telephone number, and that is far from an exhaustive list. You may want to force the end user to stick to a strict convention, or you may want to allow them complete flexibility. What might you want to happen if they enter something that doesn’t look like a telephone number? This is a very trivial example, but you can see at a glance, that something that looks straight forward can incorporate a high degree of complexity. If you don’t invest the time and effort upfront in describing exactly how you want your software to work, it may create delays, or lead to the software developer making these decisions in your absence that may or may not be inline with what you would ideally like to see.

A properly defined software specification will require a significant upfront investment of time, and it wouldn’t be unusual for this to account for 10-20% of the overall development time. Since only you know for sure what you would like your software to do, you are the person best placed to produce such a document. It will be arduous, it will force you to ask questions of yourself that you have not yet answered, but ultimately it will go a long way to ensuring that you get what you want and within the budget you have.

4. Different languages, time zones and cultures will create unforeseen difficulties

Some of the most cost-effective outsourced software development can be found in India. For those of us living in the Western World, it creates a challenge when it comes to working hours, as there is little overlap. Being able to talk with, and communicate effectively with your developers either requires a passive, and ultimately frustrating medium like email, or for you to be available the sort of hours that suit them.

Cultural differences could create an even bigger challenge. A startup with which I did some work was based around the sport of Curling. They had chosen to outsource the development to India, and it won’t surprise you to hear, that Curling is not a popular or well known sport there. A failure in writing an adequate software specification, coupled with a complete lack of appreciation as to what Curling is and the basic rules surrounding it created much friction between the company and the software developers. This set this business back by months as iterative products were delivered that represented a ‘best guess’ at what it was supposed to do, and more often than not the best guess was a wrong one.

5. Own your intellectual property

You’ll have been smart enough to ensure that you retain ownership of everything used to create your product – the source code, the assets and everything else associated with it. A reputable software development house will see this as the norm and have no problem in handing this information over.

The problem arises in the knowledge gap. If you are a technology business, and the very essence of what you do is embedded into the software your customers use, and that software was built by someone for hire, who has no additional interest or involvement in your business, then you are going to suffer a knowledge deficit.

A technology-based business should own and control the technology with which the business is crafted around. A failure to do this will only seek to cause problems in the long run. If you have outsourced the development and your business is starting to achieve some critical traction, the sooner the technology can be bought back in house and under control the better. Only then will you be able to grow and evolve the product in the way that your customers will most appreciate.


Outsourcing can provide a quick solution to readying a prototype, but it is often a poor solution to building an MVP that delivers real value to prospective customers. It will likely prove to be several times more costly than forecast, be somewhat detached from what you actually wanted, and fail to fulfil the needs of your customers.

If you can neither afford nor convince a technical co-founder to come on board, outsourcing can be considered as a last resort, but only if you are willing to do the work in building a complete specification for what you want. This will save you time money and pain in the months to come.

images supplied under a Creative Commons License by Daniel X. O’Neil and wiredforlego.

Share on Facebook9Share on Google+1Tweet about this on Twitter8Share on LinkedIn4Pin on Pinterest0Share on Reddit0Email this to someone

Add a Comment

Your email address will not be published. Required fields are marked *