Startups — Internal or outsourced software development?

Whether to use internal or outsourced development, or a mixture of both, is an important decision for tech startups. With a high demand for developers it isn’t as simple to recruit top talent by offering the market rate salary or a chunk of vested equity. Whether a startup should keep development internal or is suitable for using outsourced development is a massive decision that can easily make or break any new venture.

It is from some personal experience and reflection on using outsourced development that this article is based. The information is broken into two stages. Firstly, three key pre-development tasks are addressed that founders should complete before considering which development route to choose. Afterwards a set of factors that will influence the decision of using internal or outsourced development are listed before finally summarising these factors into a table. This article aims to help founders use a repeatable process of eliciting key factors to make effective development decisions.

Pre-development tasks

All of these pre-development tasks should be a priority to keep internal. The results of these tasks will define what a startup should focus on and how the development should be approached.

1. Validating a problem

A validated problem concerns establishing that the identified problem exists and whether a suggested solution will solve that problem. The Lean Startup and Sprint are both great resources to help with testing a problem hypothesis effectively. Both books will help minimise the resources used to test a hypothesis such as through using designs, mockups or prototypes before finally testing the prototyped solution with potential end users.

The most common time a problem isn’t validated is during a startup’s early stages, when uncertainty is high. During this time founders may have lots of ideas and problems they want to solve and different questions that need answering. Committing resources to development is an expensive endeavour regardless of whether internal or outsourced development is used. Making sure new functionality is actually beneficial should be a founder’s first priority. It is the responsibility of the founders to fully understand and be immersed in the problems they are trying to solve.

2. Drafting technical requirements

Once a problem and idea has been validated a solution can be drafted through technical requirements. A key distinction should be made here between approaches for the validation of a problem and producing an actual solution. During the problem validation stage a startup should utilize the quickest and easiest design or technical approaches to validate that the problem exists. The core aims for problem validation is speed and learning. In contrast, technical requirements are for when the problem is validated and a production ready system or single piece of extra functionality is required. Technical requirements aim to ensure any new development is of high quality and also to estimate the required development effort to achieve this.

Technical requirements should document the solution to a validated problem as a set of functional requirements. A key part of eliciting these requirements is identifying the minimal required functionality that solves the validated problem and the technology that is suitable for its implementation.

Minimising what is developed to solve the problem is an essential approach to allow for quick feedback. This approach increases the speed of learning how to optimally solve the validated problem. The optimum solution is never obvious initially!

Making a technology choice internally is also encouraged. Asking a freelancer or development firm to select the most suitable technology will often result in usage of a language and set of frameworks that they are most familiar and skilled with. The reason for this is they can naturally develop faster and to a higher quality using what they are most experienced in. Following this approach helps keep their costs lower and also produces more predictable results. Their ultimate aim is to guarantee they’ll meet the specifications and deadline set. Unfortunately this is a sub optimal approach. The technology the outsourced development route is proficient in doesn’t necessarily equate to the most effective long term choice. Obviously this factor isn’t always true. Some outsourced development firms have proficiencies in numerous languages although this also doesn’t necessarily mean they will choose the best programming language to use.

Another risk that does remain is in how a problem set can be communicated effectively. The context of the problem being solved can be difficult to fully understand in a short period of time making for a challenging task for any outsourced development route.

The most important result of technical requirements is to set expectations, make clear deliverables and to draft out the minimum version of the solution (to allow for change!).

3. Current solutions to functionality requirements

The final pre-development task consists of thoroughly looking at the development ecosystem for each piece of functionality that is required. Founders will need to weigh up whether an existing solution covers the needs of the technical requirements or whether a more bespoke solution is needed. The answer here is never black and white. The skill here is in determining what functionality is essential and what can wait until a later date. Taking this approach seriously will help founders make optimum cost and time decisions as it is always more expensive to create your own solution as the development also incurs ongoing maintenance, bug fixing and more context switching between pieces of work for developers. Founders should aim to look at both open source solutions in the programming languages they were thinking of using as well as an analysis of any SaaS products on the market that may cater to some of the technical requirements they have.

Factors for development route decision

At this point the idea is validated, technical requirements are drafted and the technical requirements that don’t have a suitable existing solution have been identified and will need to be developed. Now founders must choose on a development route for each piece of major functionality being developed.

1. Quality

Quality should be at the forefront when making any decision for software development. Regardless of whether a startup brings on employees or wants to use outsourced development it will be essential to assess the code quality they can produce. Allowing low quality at an early stage can lead to catastrophe in production where it becomes harder to update and maintain. A common term to encapsulate this is “technical debt”. Technical debt refers to “the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution”. This simply means a development team will pay the price through fixes and maintenance for prioritising producing code quickly over focussing on a suitable quality long term solution.

When bringing on an employee it’s essential to do quality checks during recruitment to validate they are a high quality candidate. This same approach should also be the case when considering outsourced development. Before committing to any outsourced development you should aim to:

See produced code — This may not be possible for most projects due to non disclosure agreements however ask anyway and find out if there are any internal or personal projects that can be reviewed by a technical founder or friend.

Talk to clients — Try and talk to at least three of their clients that you have found yourself (not just the ones they want you to be exposed to) and ask about:

  • Code quality — Is code lowly coupled and highly cohesive? Are they having any issues or maintenance problems? Is the code organised and well structured?
  • Speed of delivery — Were they on time? Did they break down the delivery into agile sprints effectively for you to review each stage?
  • Flexibility — What happened if requirements changed, was this a problem? What happened?
  • Communication — Could you speak to them easily whenever you needed? Was their any mis-communication over the project requirements?
  • General — What are the main problems you had using the company / freelancer? Overall would you recommend them?

If you are looking at hiring someone internally or a freelancer then you can get them to perform a code test to help vouch for their quality. One idea to get value from the recruitment time investment is to get a candidate to solve or discuss a problem that the company is facing at the moment as a technical test.

In terms of legalities the use of employment contracts to protect a company and employee when hiring is paramount. In the same instance startups should use legal contracts to detail out the development that will be done with any of their outsourced development options. Accountability is vital whichever route is chosen. Ensuring solid contracts through well scoped out work will mean there is less to worry about if there’s an issues down the road. Checking any contracts with a lawyer prior to signing the work is recommended to make sure both parties are protected.

For groundbreaking or mission critical systems the quality becomes paramount. Systems like these require high collaboration and testing throughout development. The solutions are also what makes a new venture valuable meaning retaining this development knowledge internal is highly favourable. For well defined functionality such as blogs or messaging the need for a bespoke solution is low. Instead this is where open source or SaaS products may suffice for the technical requirements. This type of functionality highly favours outsourced development options that have already developed this functionality.

2. Cost

One argument some founders may use for outsourced development is it provides a cheaper cost due to labour arbitrage. Although this can play a factor in the decision a cheaper hourly rate or overall project cost does not necessarily mean cheaper development overall. The quality of the code produced by an experienced developer working internally may be far more expensive initially but over time will often save money on maintenance and reusability if it has been developed well. Another key component is paying someone internally means that training and skills are retained in the business. Someone internal naturally becomes more valuable over time providing they stay for the long term. This leans on internal being more effective if the cost of outsourced versus internal is similar. Outsourced development on the contrast allows for short term development when something small is needed. However the team or freelancer may not always be available when their needed. If an outsourced development route price is lower and the quality is vouched for then outsourced can be a cost effective option. To gain more accurate cost predictions the importance of technical requirements can be emphasised even further as it allows for fixed costs to be determined based on explicit functional requirements.

3. Time frame for delivery

A clear benefit to outsourced development is work can usually start immediately (providing you have the specifications for what you need). If the time frame is important then outsourced development becomes an appealing choice. It is also arguably faster to develop with well established outsourced developers if they have well formed workflows or have existing modules of codes that can be utilised in your project or new feature set. Two main factors that influence the importance of time frame for delivery are deadlines and competition.

Startups can often come to a divide in choosing whether time of delivery or quality is more important when releasing a new product. For instance a startup with limited time to release a product at the start of the academic year aimed for students will need to make a decision on what’s more important — meeting the launch deadline or ensuring the product is of a high quality before launching?

Another consideration is competition. Whether a startup is entering a new high growth market or not will play a large part in a startups overall strategy. Is the startup moving into a space with lots of competition or is it a new technology? Is there weak customer lock in or can the technology attain network effects? If a startup is producing a new technology and can attain network effects then speed becomes a fundamental factor. The first major business to attain a large scale will be difficult to beat due to network effects. Amazon and Facebook are great examples of services that raised large amounts of capital to pursue high growth and attain network effects quickly. Make or break startups requiring high growth that are also well funded may look to use both internal and outsourced development to keep ahead of the competition.

4. Future requirements and skill retention

What are the likely future requirements for the application? Is the application or feature a one off or a core part of the business to be repeatedly improved and updated? The closer the development work is to the core value of what the business delivers the more a startup should aim to keep that piece of development internal. It is with a startup’s most core components that it solves its most vital problems. These core components of software are what make a startup increasingly valuable. Keeping the knowledge of these components internally should also naturally be a high priority.

Outsourced development options are effective when the functionality is well defined and is not new or groundbreaking. Some well defined examples could be adding a chat, blog or e-commerce solution to a technical product. If the requirements for these are unlikely to change in the future then outsourced development may be a great route to use due to a low need for skill retention.


Before considering which development route to use founders should prioritise to:

  • Validate the problem exists and that the suggested solution will solve that problem.
  • Turn the validated problem into precise technical requirements that will set the deliverables, expectations and the minimum functionality required to solve the problem.
  • For each piece of functionality required check existing technical solutions (open source modules and SaaS products) and decide on whether to use an existing solution or not based on cost and whether it meets the technical requirements.

Summary of factors influencing when to use internal or outsourced development

Finally for each piece of functionality that doesn’t have a suitable existing solution founders can analyse the following summary of factors to help decide which development route to use. Whether you use internal, outsourced or a mixture of the two it isn’t important, only that it’s effective!

If I’ve missed anything please leave a comment below! Happy new year, have a great 2017 and thanks for reading.