Technology leaders are often faced with the difficult decision of choosing whether to build software or buy it from a vendor. On the surface, packaged software appears to kickstart efforts quickly. However, customization is typically required and integration can be an overlooked challenge. On the other hand, building software in-house predictably ends up being a long, expensive process as it is not uncommon for costs to rise significantly above estimates.
The single most important factor to consider in a build versus buy decision is the long-term strategic importance of the capability. Build options are compelling for software that generates a strategic advantage, creates an economic moat, or aligns with the core competencies of the organization. This is generally true even when it is marginally more difficult or costly to do so.
Core Competencies and Market Differentiation
A recent study found that companies are increasingly looking at market differentiation when making build versus buy decisions. For example, 72% of respondents chose to favor in-house builds for customer-facing applications. Software that directly affects revenue and market positioning has different considerations than back-office solutions or cost reduction efforts.
Consider that applied search relevancy is a core competency for Google. Intelligent searches return exactly the content you want. Search relevancy is at the heart of much of what Google does, thus it simply wouldn’t make sense for Google to outsource key parts of these solutions.
Building software forces an organization to grow its core skills and competencies in that area. It builds a foundation for adapting and extending the capability into future offerings. These are important advantages for capabilities that provide market differentiation. Additionally, you have fine-grained control over what is built and how it works.
The bad news with building software is you have to maintain it forever. However, if the capability is a core competency, the good news is also that you get to maintain it forever. There are distinct advantages to each path, so formulate return-on-investment calculations and consider the tradeoffs that make sense for your organization.
MORE FOR YOU
Values and Adherence to Customer Promises
Organizations must also consider their principles and values, as outsourcing technology requires certain tradeoffs. Consider if any critical or sensitive data is being given away. What are the ramifications of housing this data externally? If a company’s reputation is built on keeping customer information safe, severe damage to the brand can result if vendors are victims of cyberattacks.
For example, management of a customer’s digital wallet is a core part of Paypal’s brand value and promise. They wouldn’t share customer wallet information with external parties unless specifically designated by the customer. When customers sign up for services, they agree to designated rules and privacy measures. Thus, any software vendors that have access to relevant data must adhere to the same level of security and privacy.
Analyzing the Return on Investment
Each option has costs over the lifecycle that are typically underestimated when considering the total cost of ownership. Building software in-house requires hiring people, managing the development organization, and executing at a high level. The resulting software needs to be maintained, so either you have to set aside two people (to maintain redundancy) or allocate a net new maintenance item for one of your teams.
Consider how much of the problem is solved by packaged solutions. If buy options only cover 80% to 90% of the requirements, then further decisions must be made on cutting scope or paying for customizations. Build options are sometimes chosen so you get everything, but how critical is that last 10% to 20%? For capabilities that don’t fall into the strategic categories described earlier, it may be beneficial to approach the decision from this alternate direction before deciding to invest in building custom software.
When contemplating software purchases, consider integration with existing systems. This task is often underestimated. Few software solutions are standalone, almost all of them need to share data or interact with other systems. This will add time and effort to the equation.
Generally, customers can’t make the vendor change how their software works. In most cases, they are limited to attempts at influencing the direction. Thus, it is the paying customer that usually needs to adjust to the will of the vendor. It’s easy to miss the implications of this when going with the buy option and mistakes of this nature are potentially costly, as it can be difficult to unravel everything and move in a new direction if needed.
Build versus buy is typically not an easy decision to make. However, if you drive the decision based on the capability’s strategic value to your organization, you’ll make a better long-term decision as opposed to over-indexing on the short-term costs and benefits. Evaluate your company’s core competencies and customer values. Then, analyze the cost versus benefits for both build and buy options. Once you have this data, the decision will be much more straightforward and, likely, fit your company’s needs and resources better.
