Build vs. Buy: When to Buy Software or Build It Yourself

“Should we buy this software or should we build it?” The build vs. buy question is both one of the most common and one of the most challenging dilemmas facing product managers.

Juggling your company’s immediate needs with long-term goals is always tricky, but when it comes to purchasing a tool to make your team’s lives easier, managers tasked with the decision to build or buy often struggle in what seems to be a comparison of apples to oranges.

In the case of software, the dilemma becomes increasingly difficult as most enterprise companies have the resources and talent in-house to build the software. It thus becomes less a matter of “Can we do it?” and more a matter of “Should we do it?”

3rd party mobile SDKs are common

Commonly, the ‘build vs. buy’ dilemma comes to an abrupt end when companies are reluctant to integrate, or even forbid integrating with, third-party software development kits (SDKs) of any sort. This is almost always fallacious thinking as the vast majority of app publishers already work with a wide array of third-party tools.

In fact, the top 100 apps in the App Store average no fewer than 6.72 different SDK integrations, covering a variety of functions from crash analytics to Facebook social logins to review management:

Often, third-party software is given a bad spin, seen as something foreign or invasive in an otherwise pure app. What it really comes down to, however, is delegation. By integrating third party software, you’re neither contaminating your app nor admitting that the software solves a problem you couldn’t solve with your own code. It simply means that you’ve chosen to delegate a specific business function to allow you to focus on your core app; you’ve chosen not to reinvent the wheel when there is more valuable work to be done.

To see if your app has integrated any SDKs, look at the eleven features shown in the chart above. If you’re using any sort of tool for analytics (e.g. Flurry, Google Analytics), monetization (e.g. Google Mobile Ads), or social integration (e.g. One-tap registration with Facebook), you’re already using third-party software. You’ve already made the conscious decision to delegate certain aspects of your business so that you can focus on what really matters.

5 common considerations before you decide to build or buy

How you answer build or buy ultimately comes down to a five common considerations:

1. Time to market: Do you have an immediate need for the software, or do you have time to develop it in-house?
2. Total cost of ownership: How much will the software cost to buy? To build?
3. Features and functionality: How well do existing out-of-the-box solutions meet your needs?
4. Knowledge and expertise: Do you possess the resources and expertise to make the software as good or better than current solutions?
5. Core competencies: How central is the software to your business, and what would you be giving up to dedicate a team to its development and maintenance?

Let’s look at each consideration in-depth to help you make your decision.

1. Time to market

Most third-party software can be integrated into your app in mere minutes, often with minimal to no technical resources. An in-house solution, on the other hand, can take a dedicated team months to develop. According to a VMWare survey of IT decision makers, the average medium-sized IT project took five months to complete, with 17% of respondents reporting average projects taking between 7-18 months.

To further complicate matters, large in-house IT projects are notorious for exceeding their anticipated timelines. A report by McKinsey found that 7% of large IT projects were delivered late. 

While in-house solutions can be developed in a reasonable time period, they are notorious for exceeding both their planned timeline and their estimated budget. If you need an immediate solution to the problem the software will solve, buying third-party software will speed up deployment, ensure a faster reaction time, and give you the confidence of a guaranteed timeline.

2. Total cost of ownership

Next, ask yourself: Is it cheaper to build or buy this software? What about maintaining it?

With third-party software, you know exactly what your cost is upfront. Perhaps it’s fixed, or perhaps it’s variable based on seats or monthly active users. Either way, pricing should be transparent and predictable month-over-month. This subscription covers the regular maintenance you’d have to account for with an in-house solution but has the benefit of being spread out over hundreds or thousands of clients. The end result is almost always a lower upfront cost and a lower recurring cost when you opt for third-party.

For in-house solutions, pricing is rarely predictable. According to a McKinsey survey of IT executives, large IT projects run over budget 45% of the time, while delivering 56% less value than planned. The same study found that 17% of projects go so bad that they “threaten the very existence of the company.”

Additionally, consider your opportunity costs: If you allocate existing resources to building and maintaining this software, what will you have to give up? Where are you taking resources away from?

Effective in-house solutions typically require a dedicated team, meaning you’ll have to permanently move developer talent away from current projects or hire additional hands. To assess your opportunity cost, consider the best use of that talent and where your top developers can have the highest impact.

3. Features and functionality

When evaluating out-of-the-box software, consider: How well do existing tools meet my needs?

With in-house solutions, you have unlimited flexibility to create a product that meets your goals. As we saw in prior research cited, however, this advantage can be deceiving. 56% of large IT projects fall short of their original vision and are launched with sacrificed features and value (McKinsey) and project success rates inversely correlate with the complexity of its features, accounting for the 19% of projects that never reach market (Standish Group).

With third-party software, customizability can be limited. You do, however, have the freedom to shop around and evaluate competing vendors on the basis of features and functionality to find the product that best meets your needs. Often, you can even try out software, through demos, trials, and proofs of concepts, at no risk. You might even be able to negotiate future features in your contract for a premium if you represent a significant portion of the third-party’s business.

There’s a case for both buying and building the software you need. Building in-house solutions gives you total flexibility over your product’s design, but comes with the risk of a challenging execution. Buying software may require sacrificing some of your envisioned functionality, but allows you the freedom to freely evaluate options to find the best available fit.

4. Knowledge and expertise

Ask yourself: Do I possess the resources and expertise to make the software better, or equally as good, than those solutions currently available?

With third-party software, you receive both the technology and the expertise. Most enterprise plans offer a dedicated customer success representative who can help you get the most out of the software. These on-staff experts know the art behind the science, having worked with clients of all sizes to pioneer best practices, and can work with you to create a personalized plan for success.

In-house solutions may have the technology down, but still see inferior results without the same level of subject matter expertise unless the software falls directly into the business’ core competency. Of course, companies can, and often do, hire experts on-staff for specific business functions. Doing so, however, greatly increases the project cost and true experts are few and far between—and those who do possess the required level of expertise are often already working for third-party tools.

To demonstrate the difference between the art and science of software, consider the example of push notifications. The basic technology (the science) is more or less the same regardless of which provider you use as it’s dictated by strict OS requirements. The impact of this technology, however, varies greatly, depending on how you employ it (the art). Without the art, push notifications often come off as spammy or annoying and are the frequent reason people uninstall apps. 

Great software isn’t built in a vacuum. It’s the product of years of trial and iteration, of working with your stakeholders to co-design something that meets both your needs and the needs of your customers.

Unless the software in question relates directly to your core competency, building in-house means replacing years of iteration with assumptions. The product might get the job done, but you’ll miss out on the team of experts committed to your success that comes with most enterprise-level software subscriptions.

5. Core competencies

Finally, ask yourself: Is my core competency aligned with building great CEM software, such that it would be faster, cheaper, or more effective to build the software in-house?

If you can confidently answer “yes” to the question above, building the software you need in-house will be to your advantage.

If, however, you’re even a little uncertain, delegating the business function that software solves to a third-party can save you the future headaches and risk associated with software development. Buying a third-party isn’t a matter of weakness or defeat; it’s a matter of resource allocation. You’re making the decision to conserve your limited resources—time, money, and most importantly, talent—and investing those resources into areas with higher dividends: the core features of your app.

Wrapping up

In the end, only you can make the decision to buy or build the software you need. We hope this post helps you reach your decision with confidence by detailing each of the key points to consider when evaluating the ‘build vs. buy’ dilemma in the context of your business.

The post Build vs. Buy: When to Buy Software or Build It Yourself appeared first on Alchemer.