Should Startups Outsource Software Development or Not

It’s a decision that can make or break a startup: Do you invest in in-house resources to create your product or do you outsource software development to a third-party developer? On the one hand, as a startup, shouldn’t product development be a core competency? On the other, surely it’s better to go to market as quickly as possible and allow the “experts” to help you get there and avoid all the pitfalls of technology development.

Both approaches have their pros and cons and the decision is by no means straightforward. The answer depends on many business and cultural factors and the type of product you are looking to build. Nevertheless, to outsource software development is a decision that needs to be taken early on in a startup’s life and can leave founders in a quandary as to the best approach.

At Altar.io we have worked with a number of early-stage businesses — as well as providing product innovation for larger corporates — and we have learned many lessons on how to tackle such a momentous decision. In this article, you’ll find a structured approach to help you decide if you should outsource software development.

The outsource-or-not decision tree

The answer to whether or not to outsource software development requires you to break that complex question down into simpler steps.

Step 1:

 Is technology part of the core value proposition of the product or is it a vehicle to solve a business need?

For most startups there are two possible answers to this, either:

1. Technology is the core proposition; or
2. Technology is the means being used to solve a business issue

In general, if your business comes under (1) then you are more likely to develop the solution in-house. If it’s (2) then your startup should probably outsource software development.

For example, consider Loopback, a Node.js framework that enables developers to create dynamic end-to-end REST APIs with little or no coding. Here, technology is pretty much the only proposition so Loopback would come under (1). Contrast this with Airbnb, which enables property owners to monetize their homes and enable travelers to have a unique experience in the city they are visiting. Clearly, the key value proposition of AirBnB is for property owners and travelers, meaning the business comes under (2).

Generally, businesses that come under (2) and are using technology merely as a way to solve a business issue should consider outsourcing, for reasons we will discuss later.

Sometimes the distinction is not so clear. Consider GitHub, the platform for developers to host and review code, manage projects and build software. Whilst technology is the core proposition, the platform itself is there to solve a business issue for developers. This creates a grey area. 

Let’s proceed to the next steps.

Step 2:

 What is your target audience/who are the buying customers?

Usually, the answer can be summarised as either:

1. Our product is aimed at technology specialists/developers; or
2. Our product is aimed at consumers/business customers

Returning to our previous examples, Loopback and GitHub come under (1), whilst AirBnB comes under (2). However, again this can create grey areas that can only be solved by answering one more question:

Step 3:

 Does your product involve a technological “secret sauce” that makes it unique?

By this we mean either the technology itself is proprietary to your startup, or the way it’s being implemented is unique. The two possible answers are:

1. Yes; or
2. No

This clarifies the GitHub “grey area”. The platform is targeting developers, but neither the underlying technology not its implementation is unique or proprietary, so the answer is (2). It contrasts with Loopback, which would come under (1).

Let’s take a look at a visual representation of the 3 steps I mentioned:

So should you do it or not?

As illustrated in the outsource-or-not decision tree, it’s generally inadvisable to outsource software development when:

• The business has technology as its core proposition
• The end consumer is technology people; and
• The technology is either proprietary or unique in its implementation

In any other scenario, a software project can either be built in-house or outsourced (or possibly a combination of the two), depending on your willingness and other circumstances that might affect your business case.

Case studies from very successful companies

Consider Alibaba, the multibillion-dollar company outsourced software development to a firm in the US.

In Liu Shiying and Martha Avery’s words: “At the time, overseas development talent was still in short supply and the US had the skills Alibaba needed to compete with e-commerce giants like eBay and did it all behind the Chinese internet restrictions.”

The Alibaba case shows startups come in all shapes and sizes. Not all are co-founded in a garage with the right tech person in charge from day one. And there are many others that, for one reason or another, decided to outsource software development at the beginning of their journey.

Upwork was built using mostly contractors. By hiring 150 of their 200 product and engineer workers freelance, they benefited from the world’s best talents while proving the relevance of their project. This sort of self-fulfilling advertising is as cheap as it is genius.

Skype outsourced its platform construction to an Estonian trio of developers. Founders Niklas Zennstrom and Janus Friis proved back in 2003 that international freelance collaboration was no doomed venture, which many thought at the time.

WhatsApp launched with just a quarter-million US dollars in starting capital and with a priority to keep operational costs at a minimum. To develop from their Mountain View base would have been impossible. So they looked into Russia, where co-founder Jan Koum recognized some of the world’s best offshore developers conduct their services. Igor Solomennikov, first iOS developer, started as a contractor and later joined the team in California on a full-time basis. Distance between base and freelancer should prove no cause for concern when startups can now reach around the world as easily as they can across the street.

TransferWise state that they do not “do offshoring, outsourcing or use consultants” but they admit to a number of “independent workers” who, if you dig a little deeper, are developers and technicians emanating mainly from Ukraine. It is interesting to see that some startups that outsource software development prefer to present an in-house vibe to customers.

On the other hand, you have YCombinator. They decided on a different approach.

Michael Seibel, partner @YC, states it straight: “Reading YC apps, I’m seeing too many founders who have raised some seed capital and who outsource engineering to cut costs. This is a common error that is a huge red flag for future investors and is often much more expensive in the long term than having a technical co-founder.”

Joel Gascoigne, Buffer CEO and Founder, seems to agree with this reasoning. He proposes 3 clear points to support the thesis that tech startups should not outsource software development. These points summarise most of the criticism I’ve heard during my many years attending events and talking with founders:

1. “Your goals and a freelancer’s goals are completely misaligned”.

Joel’s point rotates around the fact that freelancers and agencies want to make money, while a founder wants to find the product-market fit for his startup. On the one hand, if the agency or freelancer fixes a price for the MVP, they will take steps to ensure that the scope does not go beyond what they budgeted for. On the other hand, a founder eager to find the product-market fit needs to put his product out as soon as possible and iterate from there. And this is quite opposite to what freelancers and agencies normally want you to do.

Freelancers and agencies normally want to work in a “known problem, known solution” environment (e.g. a restaurant that needs a website represents a situation where both the problem and the solution are known: easy to know what should be on a restaurant’s menu), while tech startups operate in an “unknown problem, unknown solution” (no-one knows if the problem is real and the solution is appropriate until the new product is being used). That’s why there is often misalignment!

2. “It gets you into the wrong mindset of what it takes to get a product off the ground”.

This relies on the fact that the majority of us think that success depends on getting a product built, and that’s why we need to find a tech person (or entity) to get things done if we’re not capable (i.e. coding).

What Joel thinks we need is to concentrate on is the aforementioned product-market fit, which can be achieved by uniting a set of interactions with no code at all (instead of using Wufoo, Google Forms, Unbounce, etc.).

What’s the outcome of this digression? That, later down the road, any decent coder will be interested in joining a startup put together without code and whose early traction shows great potential — that’s somewhere they can make a big impact.

3. “The founding team should wear every hat”.

The co-founders should do everything in the beginning. Why?

It provides the right mindset: the founding team can make anything happenIt cultivates a deep overview of the different areas of the business, making iteration super-fast and decision-making easier and smootherWhen at the point of hiring, you’ll know the difference between average people and great peopleYou develop a passion for all of the different areas you get involved in.

What Joel suggests is that each founder should find the hacks and tricks to validate his assumptions with the weapons they have in their armory. For at a certain point you’ll have such an interesting proposition that a good technical co-founder will come on board.

It would be redundant to go into the big list of successful startups started by (at least) one in-house tech partner as there’s simply so many. Apple, Google, Microsoft, Uber, Airbnb… you see what I’m saying.

Still not sure what to do? Here are the pros and cons of each approach

Outsource Software Development — Pros

Timing

You have access to technical resources from the very outset. Obviously, you’ll need to go through a procurement phase, but that time will be way less than what is required of any stronger commitment (i.e. onboarding the right CTO or identifying your key first employees). On top of this, as your idea is still a “napkin idea”, you may not be able to confidently attract top talent yourself, so it’d be very difficult for you until you find the right person to onboard.

Focus

As a founder, your goal is to validate your idea as soon as possible. The reasons for this are to gather investors and the interest of top talent. The earlier you can begin to do this, the better. You don’t want to waste time onboarding and managing developers (which is in itself very hard!) but you can concentrate on your business/sales/marketing duties to build the foundation of your business’ viability.

Access to great value for money

This applies to certain regions only. Tier 1 talents may ask you for a significant wage, which can be too much for a startup yet to properly kick-off. According to this report by James Wise (Partner at Balderton Capital), you can see the average yearly salary asked by developers in different EU Countries. 

On the expensive side, we’ve got Switzerland (average 90,524 USD), Norway (86,042 USD), Denmark (75,758 USD) and UK (70,500 USD), while on the cheaper side we find Portugal (22,549 USD), Greece (24,805 USD), Spain (34,229 USD) and Italy (34,229 USD). On top of this, it’s intriguing to see that the amount of STEM Graduates does not follow the same price curve, meaning there are cheaper countries that hold a significant technical workforce.

Outsource Software Development — Cons

Misalignment

Freelancers (and agencies) aims to make money, while your goal is to minimize the product as much as you can to then iterate on top of it. Freelancers and agencies might push you to build something bigger than you need.

Dependency

Freelancers or agencies may not follow the industry standards for project organization and documentation. If this is the case (be it TDD (Test Driven Development), CI/CO (Continuous Integration/Continuous Deployment) or other formats), their code will be very difficult to follow by any other developers that join the team later or occupy his seat if he leaves. They will also be the only owner of the key for your castle. So if you outsource software development be sure the one you’re outsourcing to follows every relevant standard!

Tricky Agreement

Be aware of the “lock-in nightmare”, especially with agencies. If you want to be able to work with other parties in the future, be sure you sign the right contract so that you can bring your code to new players. Otherwise you’ll end up in marriage by force and have to call upon your lawyers for the divorce.

Besides the lock-in nightmare, another aspect to be careful of is all specifics concerning Intellectual Property. You don’t want to use a code that belongs to someone else and prevent yourself from iterating your business!

Doing it In-house – Pros

Alignment

Your team has the same goal as you do: to grow the business, and to do so while following a lean, iterative approach: all of you want to minimize the risk of failure while speeding up the validation phase.

Growing professionally and personally, as a team.

In another article I talked about how being in the office can make all the difference in a Startup. Taking back words from that article: “As entrepreneurs, we love to challenge yourselves. So when we come together, we challenge each other, exponentially expanding our creative potential. Bouncing ideas, killing bad concepts, collaborating to refine a singular, golden vision.

Also there’s the Harvard Business Review: “Employees with a neighbour of alternate skills at the desk next door received a 10% “performance spillover”, as observed across three types of worker: productive (who completed tasks quickly but lacked quality), quality (who produced superior work but did so slowly), and generalists (average across both productive and quality dimensions). 

Management could also use these combinations of workers to their advantage, say by grouping workers of opposing strengths — a “quality” worker with a “productive” worker, for example. This improved work quality across the pair to the tune of 13% productivity gain and 17% effectiveness gain”.

No risk to incur in tricky IP clauses

No agreements need to be signed with suppliers, which erases the risk of dealing with any dishonest clauses. Such shady agreements may well prevent you from using, modifying or selling the project at all, or unless you pay the supplier a lavish fee.

Doing It In-House – Cons

When Starting a Business There’s a Timing Issue: How Much it Takes to Find the Right Tech Talents

You’ve read a couple of blog posts about “66 Tips to find the perfect CTO for your startup” and you’re on your way, right? You will hear many people saying that “investors invest in teams” so “you must find your CTO“. You will start hitting tech meetups, purchasing tickets for the hottest startup events like crazy and listening to many geeky conversations trying to find your co-founder. (Don’t get me wrong, I love tech meetups, events and geeky conversations!)

If you pick the right meetups, you will meet lots of interesting people with interesting projects, and also developers that seem to be geniuses when they start dropping buzzwords you can’t understand. But how do you separate the wheat from the chaff?

You’ll take several weeks (or months) before finding the right talent that fits correctly within your team. Is it worth the risk of waiting several months to get things done?

Management Issues

Have you ever managed a team of developers? If you haven’t, be aware of what you are getting into. There are 12 Archetypes of Developers, each with its own specific characteristics. Creating and keeping a balanced dev team is a very challenging art due to these 2 characteristics of developers: (i) generally speaking, they are not the most skilled communicators; (ii) they tend to be fiercely competitive, especially when it comes to tests of intellect.

If Not an Experienced Recruiter, You Might Need to Fire your Employees/Co-Founder

Serhat Pala states it right: “Firing someone never gets easier (unless you’re getting paid big bucks to yell “You’re fired!” at people). Even if you’re happy to see someone go, you know that by firing them you are putting them and possibly their family in a precarious position and that can be tough to swallow. Research done by the Journal of Vocational Behavior says unemployed people are twice as likely to suffer from psychological problems as employed people, so the danger is real.”

Plus all the bureaucratic issues firing drums up (varying from country to country, of course). Then, well, you’ve got to consider the amount of energy and time you should dedicate to the topic.

Firing is never easy, to put it again in Pala’s words: “the best time to fire someone is before you hire them, which means you should have a thorough process for recruiting and interviewing candidates so you only hire people who you don’t need to worry about firing later”.

Key Takeaway

The choice, as they say, is yours. But whilst there are never any guarantees that the decision you take is entirely right, by ensuring you take it on an informed basis in terms of business needs, cultural fit and financial resources, you stand a much higher probability of success.

Disclaimer

: This post was originally written by Paolo Dotta, Co-founder at Altar.io and published on the company's blog.