Build vs. Buy: When to Buy Software or Build It Yourself
“Should we buy this software or should we build it?”
The question is both one of the most common and one of the most challenging dilemmas facing 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?”
How you answer build or buy ultimately comes down to a five common considerations:
- Time to market: Do you have an immediate need for the software, or do you have time to develop it in-house?
- Total cost of ownership: How much will the software cost to buy? To build?
- Features and functionality: How well do existing out-of-the-box solutions meet your needs?
- Knowledge and expertise: Do you possess the resources and expertise to make the software as good or better than current solutions?
- 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
The first question to ask yourself is: When do I need the software by?
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 in 2014 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 the Apigee Institute found that as many as 27% of app deployments exceeded their timelines. Additional research by McKinsey found that 7% of large IT projects were delivered late. Neither of these figures account for the 19% of projects that were considered failures and never reached market, and the 52% of projects that came in over budget or with sacrificed functionality, according to the Standish Group’s 2015 CHAOS Report. The study further found the larger the project, the lower the likelihood for success.
TL;DR: 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 to maintain 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.” These high-impact overruns, often referred to as “black swans,” see budget overruns of anywhere between 200 and 400% and can end in project abandonment or even bankruptcy. An earlier study by the Harvard Business Review found the same result, where one out of every six large IT projects the researchers studied fell into this “black swan” category.
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.
TL;DR: Contrary to popular belief that building software in-house will pay for itself over time, the majority of software costs go toward maintenance, not initial development—requiring interminable recurring costs and a dedicated support team. Building in-house can also be a risky endeavor, prone to both cost and budget overruns. Buying pre-built software removes this risk and any costs associated with maintenance are built into your contract to avoid any surprises later on.
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 potential significant portion of the third-party’s business.
TL;DR: 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 challenged 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 behind—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 #1 reason people uninstall apps. With the art, app messaging can be optimized for reception and conversion to grow three month retention by as much as 400%. Same technology, polar opposite results.
TL;DR: 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 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 it up
In the end, only you can make the decision to buy or build the software you need. I 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.
If you have questions or additional advice for choosing whether to buy third-party software or to build it in-house, I’d love to hear your thoughts in the comments below!