Developing In-House vs. Sourcing External Solutions: 5 Steps to Help You Make the Call

Whether you’re a corporate looking for innovations to complement your core business, an individual developer working on your first application, or if you’re a well-funded startup with skyrocketing growth, you will keep facing the question of developing in-house vs. integrating a third party solution.

I was speaking about this challenge at the recent Product Manager Meetup in Hamburg, and as a result of the overwhelming feedback I got from attendees, I want to share a summary with you. This post covers the benefits of external solutions, advantages of in-house development, and it provides a simple framework for decision-making when challenged with this recurring question.

What are the benefits of implementing third party tools*?

• It is important to differentiate between development outsourcing and implementing external innovations — third party tools are ready-made solutions, whereas outsourcing is more comparable to in-house development from a resource-allocation standpoint.

There are at least 6 points about third party tools that you should consider:

1. Third party solutions are existing, developed services (even if it is in alpha/beta stage), which you can start using right away. It is pretty easy to gather feedback about the solution from the current users (e.g. your clients, trade shows etc.)
2. These services are working with other companies (including your direct & indirect competitors); they share best practices and offer a readymade solution for your problems (someone else out there has very similar challenges to yours). The service they offer is their core business, so you can assume it’s in their best interest to continuously improve their product.
3. External solutions typically come with customer- and integration support services. They most likely have already integrated with other companies and have analyzed all the use cases to provide a smooth integration.
4. Their pricing model is usually reasonable, and often subject to negotiation (typically, the longer contract length or volumes you commit to, the cheaper it becomes).
5. Do not underestimate going through a testing phase. Do a pilot project in a small, contained scope to get an accurate estimate of how scalable the solution is, and how capable the solution is of addressing your needs. Testing options are often available for a fragment of the cost.
6. Don’t forget that implementing third party solutions is a quick win for your business. Do not underestimate the benefits of taking a short cut! Your competitors are already benefiting from them.

The benefits of developing solutions in-house

1. In a lot of cases, developing in-house becomes the only option when there’s no available service on the market that addresses your exact needs, or when the available tool only fulfills a fraction of your needs (thus, you still need to fill in the gap). Make sure that you thoroughly research the features of a potential solution and match them to your requirements.
2. You can avoid unnecessary dependencies, inflexibility, and implementing features you don’t need. External solutions require integration efforts from your side as well, and they are typically not very flexible with additional tools you would like to use on top (e.g. an internal monitoring and reporting system).
3. In-house development also allows you to avoid being locked-in to a contract and makes for easier cash flow management.
4. You would own (and be able to patent) the technology. It would be possible to leverage it multiple times, e.g. by providing new services to your strategic partners, having additional USPs and potentially, even a new revenue stream.
5. The most important reason to develop in-house is having flexibility and control to build customized features on top of your solutions — which are also built cohesively within your existing IT infrastructure.

Takeaways from personal experience:

It’s pretty easy to find both good and bad examples of situations when we developed something in-house or opted for an external solution. While specific examples are not currently relevant, it is worth noting that in retrospect, I can clearly see what the right call was based on the product outcome.

One time, I spent an exorbitant amount of time integrating a service that couldn’t even solve 25% of the most time-consuming tasks we had originally sourced it for. In hindsight, the smart move would’ve been to gather detailed requirements and sit tête-a-tête with stakeholders during the test phase to avoid those mistakes from the outset.

Another “famous” case I recall was when the newest in-house solution generated so much data in first two days that it immediately became indigestible (producing over 40,000 actionable rows on a spreadsheet). We had to switch it off by the end of the week and completely rework the solution. The takeaway here is to think a few steps ahead and make sure to evaluate how the end user will actually interact with your product. Because they are not “client-facing,” it is very common for internally developed solutions to have under-tested controls and functions.

Here’s the five-step decision-making guide:

Going over the following steps and asking relevant questions will help you make more accurate, data-driven decisions on whether to develop in-house or rely on external solutions.

Step 1

This is a starting point for any evaluation. You should focus in-house resources (including development, knowledge, and research) on the core product or service offering, and use best practices and external solutions for all the supporting functions.

However, in reality, company or product needs can be so specific, that there are simply no relevant external tools available on the market yet; or if they do exist, they come at high monthly- and integration costs. In my experience, this is a common challenge for product or innovation managers.

Step 2

Evaluate if it makes financial sense to buy an external solution. There are many benefits to implementing third party services, but if it doesn’t have a positive impact on your ROI, don’t bother.

If you’re a CTO, CIO, or CDO at a large corporate, costs are probably not the biggest concern when it comes to a larger innovation strategy. Your stakeholders would prefer developing proprietary technology, but if there’s an existing solution on the market already, don’t bother wasting your internal resources and time developing something that would just be a subpar copy. Your stakeholders will also appreciate developing partnerships with external innovators.

Step 3

If outcome of Step 2 is no, you should check what other alternatives there are. Is there any cheaper, maybe even more basic solution that can solve 50% of problems? Can you split manual work between people in the team (so each one does 15 minutes a day and half of the problem is gone)? Can you hire an intern or working student for this particular task?

Step 4

If outcome of Step 2 is yes, make sure to evaluate all hidden and indirect costs. Pay attention to the contract and additional fees, triple-check integration costs, evaluate upcoming maintenance costs, and calculate the scalability of the solution (would the tool still cover needs of your stakeholders 3/6/12 months from now?).

Step 5

Have you calculated the true costs of developing in-house? Can you spare the resources (time and manpower) to address this need? Do you have the knowledge (technology-wise) on how to build the solution? Do you have the finalized requirements/ roadmap/ project timeline? Have you done your homework? What tasks are you deprioritizing because of this development? Is it OK with your stakeholders, do you have their sign-off? Are the KPIs of success clear, agreed and timelined?

Summing up

Based on past experience, I would recommend everyone reading this to not reinvent the wheel, and stick to ready-made external solutions. My reasoning is very basic. You are experiencing challenges outside of your core business that prevent you from growing or innovating as fast as you want. There are companies out there offering you solutions for your exact needs, companies whose core business is solving those very problems. If you are confident that you can produce a better solution than what is already available, that would imply that this service can actually complement your core product portfolio, and this is rarely the case.

The motivation is simple: focus your resources on the where you can make the difference. You can always put your tech team to better use.

This post was written by guest contributor Alexander Savelyev, Head of Product at PubNative, and adapted for dynamics by Karina Schultz. You can read the original here.