In the realm of digital transformation, the build vs. buy debate is an active dialog. Over the years, I’ve been in countless conversations with our clients about this debate. I typically represent the “build” side of the dialog, so admittedly I have a natural bias. One of my favorite one-liners is, “I could build a lot of software for the kind of money companies spend on ERP projects.” But I readily acknowledge legitimate arguments on both sides of the Build vs. Buy debate.
To help our clients evaluate their options and make an objective decision, I’ve developed a simple matrix of pros and cons. In this post, I’ll share that matrix and explain each one with some background and explanation. But before we examine the pros and cons, it’s essential to start with a guiding principle.
What Are Your Differentiators?
Your competitors can buy the same packaged solutions you can. If there is a process or business function that is common and doesn’t have potential to differentiate your company, that could be an argument for a packaged solution (i.e. Buy). This is why many companies start with back-office functions for their packaged solutions (e.g. Accounting).
Consider the competitive pressures and market opportunities in your business. What differentiates you from your competition? Areas of differentiation are a good place to explore custom solutions (i.e. Build). Custom solutions tied to differentiation have clearer ROI, and a business case can be made for the investment.
Side note: Recently, it has become just as important to differentiate to attract and retain talent as it is to attract and retain customers. Consider talent in your overall strategy for differentiating in the marketplace.
Build Pros
Distilled from decades of consulting on software and data solutions are some of the more compelling arguments in favor of custom solutions. These are reasons that building a custom solution might be right for your organization.
Optimized to Your Business Needs
A custom solution lets you define and build a solution that does exactly what your business needs in the way your business wants to execute. If you’re used to “doing it our way”, or have high priority or unique business requirements, then build might be right for you.
Lower Friction Cost
Friction cost is a term used to describe the impact of change on an organization. When you implement a package solution, you are required to adhere to a process that is dictated by the functionality of that system. Different systems that solve the same business problem will have different processes for doing so. If you are going from custom to package or one package to another, change is required in your organization.
Change creates friction and increases operating costs by reducing the efficiency of your teams. Companies don’t often understand these costs because they are hard to quantify, but Adoption and Change Management helps reduce the friction costs of packaged solutions. If you suspect you might have high friction costs, then build might be right for you.
Highly Adaptable to Changing Business Conditions
You have full control over a custom solution. That lets you pivot or adapt a solution along with changing business conditions. As the pace of business change increases exponentially, this can become a critical advantage. If you want to lead the market, then build might be right for you.
Lower Operating Costs
If you own a custom solution, then you don’t have to pay to use it. You can also optimize those operating costs based on how heavily the system is used and the business value it generates. You have full control. If operating costs are a Key Performance Indicator in your organization, build might be right for you.
Note there are often ongoing or future investments to continue improving a solution. These investments are part of your total cost of ownership, but make sure to distinguish them from operating costs. These investments are aimed at added functionality that drive higher business value.
Short Cycle Time for Requested Changes
Ownership has its benefits when it comes to product enhancements. You drive the timeline and the urgency and are not subject to the release cycles of your software vendor. Lead time can be further improved with an active lifecycle management strategy and bolstered by a partnership with a managed service provider (like Core). It might be counter-intuitive, but if speed to market is important, then build might be right for you.
Retention of Intellectual Property
Retaining IP is not just about owning full rights to a concept or product. It’s also about risk mitigation. Owning the rights to the product has benefits I discussed in the “What is your differentiation?” section above, but many organizations aren’t looking to differentiate when solving business problems. Generally, these conversations fall under efficiency gains and process improvements. Often the high cost of solving a problem with a custom solution can be a barrier.
With the explosion of special purpose SaaS products, there seems to be a product to solve every problem. Consider risk in your equation, though. Many of these SaaS companies are early stage and ripe for acquisition. It’s not unusual for a product to pivot, get acquired, or go out of business. This kind of risk can be hard to quantify, but if a process or need is business critical, then build might be right for you.
Build Cons
There are some counterarguments as well, and here are some for you to consider.
Higher Capital Expense
This is probably the single most influential factor in choosing not to build a custom solution. The upfront cost of building your own solution can be a big investment. A good business case will involve an element of return on investment. When considering build vs. buy alternatives, don’t forget to factor in total cost of ownership. On paper, packaged solutions look cheaper, but consider the friction cost (discussed further below) in your assessment.
Enhancements are Directly Funded
Remember, you own a custom solution. Licensing and subscription fees of packaged software and SaaS products are basically cost-sharing models. If you’ve built a custom solution, there is no cost sharing. It is not uncommon to have multiple phases of development that, when combined, exceed the initial investment. However, you should have business cases that justify the additional investment with further ROI.
Potentially Higher Commitment of Company Personnel
Building a custom solution, as with any digital transformation, is a team effort. Even if you outsource the development, you will need to allocate time and talent from your team to this effort. The product owner is a key role often played by a leader from your company who has domain responsibilities in the affected area. Technical and business subject matter experts may be called on to advise on deliverables and priorities. Still other team members may get involved in user acceptance testing. These internal investments can also be relevant to packaged software implementations. Regardless of the choice, be prepared to commit your organization’s time to the effort to ensure a successful outcome that has a positive impact on business performance.
Will Take Longer (Misconception)
It does take time to build a custom solution, but when properly resourced, it will go a lot faster than you expect – maybe even faster than you are prepared for (we see this a lot). This misconception often stems from a history of working through under-resourced internal IT departments who are weighed down with keeping the lights on. Partnering with a firm like Core BTS that specializes in building custom solutions will drastically reduce your time to market.
No Support Available (Misconception)
Since a custom solution is one-of-a-kind, there is no immediate robust product support. It often has to be developed along with the product. This can lead to a perception that a custom solution has no available support. However, custom solutions are often (and should be) built using industry standard technologies, whereas packaged solutions require specialized knowledge. It is often easier to recruit and hire engineers with experience in industry-standard technologies like Azure, SQL, or .Net than it is to recruit and hire people with experience with a specific solution.
Additionally, product support ties you to the company that created the product. By contrast, a custom solution built using industry-standard technologies can be supported by many different organizations. That gives you the flexibility to partner with multiple service providers or change providers while retaining the custom solution – thereby minimizing impact to the business. Partnering with a Managed Service Provider (like Core) can be a great way to achieve parity with product support.
Buy Pros
Below are some reasons that a “buy” decision might be favored over “build”.
Lower Capital Expense
Much of the total cost of ownership of a packaged solution is baked into the licensing fees which are typically treated as Operating Expense (vs. Capital Expense). There can be implementation costs, and those are sometimes treated as Capital Expense. Implementation costs can include setup / configuration, customization, integration, and other initiation costs, but these are typically less than the Capital Expense of building a custom solution. Before making a buy decision based on capital expense, be sure to understand your total cost of ownership (this is covered in the upcoming “Buy Cons” section).
Cost Predictability
Much of the cost of a packaged solution is baked into the licensing fees which can make the total cost of ownership more predictable. But don’t forget to factor in costs to integrate, customize, or overcome friction (more on these later). For large software platforms like ERPs, you will have added operating costs to maintain and operate. In that case, cost predictability becomes less of a benefit over custom solutions. In either case (build or buy), cost predictability can be greatly improved by partnering with a Managed Service Provider who specializes in the type of technology support you need.
Industry Best Practices
Many software products cater to a specific industry or business process. Therefore, they’ve incorporated best practices that have been developed by working across many clients to solve the same problems. Their product features and related business processes reflect that industry knowledge.
Before making a buy decision based on industry best practices, consider your secret sauce. Earlier I asked, “What are your differentiators?” When you purchase a packaged solution, you may be giving up some of the secret sauce that makes you unique in the marketplace.
Mature Documentation, Training, and Support
Packaged solutions often have robust documentation, training, and support infrastructure. They have developed these over time so they have had time to mature. The costs to develop and maintain these services and content are also spread across the user base through licensing (i.e. cost-sharing discussed earlier), but they can also be part of an upsell the software vendor uses to increase deal size and margins.
Freemium Pricing Models
Products that are special purpose (limited functionality) but more ubiquitous can spread these costs wider and may have lower fees. Some of these products may have a “freemium” pricing model where they offer a limited set of functionalities for free. This is different than a free trial which many products also do. Freemium models are intended to get you hooked into their platform in hopes that you purchase paid services in the future. It can be a great way to start adding value at a low cost and invest as the value grows with use of the platform.
Buy Cons
There are pros and cons in any decision process. This section covers the cons of selecting packaged software over a custom solution. These are real, but sometimes little understood and rarely considered when making a buy decision.
High Friction Costs
Friction cost was defined earlier, but it might be helpful to think of this as the “cost of change”. It’s a hidden cost in many software implementations. It’s also difficult to quantify, but it is a real cost. An entire discipline (Adoption and Change Management (ACM)) has grown up around mitigating the impact of change in large software implementations and has developed industry standard methodologies like Prosci ADKAR.
I often say that technology is the easy part, and people are the hard part. Managing change is a big contributor to this sentiment. When you implement packaged solutions (especially large platforms or “1st party” solutions), there are often changes to business processes that impact how people execute their daily job functions. When that process changes, people resist the change and require additional training. That damages efficiency, and the impacts ripple throughout the organization. However, with custom solutions, this change impact is greatly reduced.
As discussed earlier, custom solutions are developed to do exactly what the business wants and how they want it – thereby minimizing the change impact. When done right, custom solutions have an intuitive user experience that reduces the need for training. Investing in expensive adoption and change management consulting is less common with custom solutions because it isn’t as necessary.
Higher Operating Costs
Most software products have either a SaaS (Software as a Service) model or charge maintenance fees (that can become significant over time). If a platform is more specialized (limited user base to spread costs) or has an expansive set of capabilities (see the section on Bloatware below), then you can expect the licensing fees to be higher. While they do typically have a lower upfront cost (capital expense), they can have higher ongoing costs (operating expense) or even a higher total cost of ownership due to the never-ending subscription or maintenance fees.
Packaged software is a shared cost model. The cost to develop, enhance, and maintain an application is built into the licensing cost and spread across the user base. The benefit to the purchaser is that it theoretically lowers your cost. However, sales, marketing, and other overhead costs are also part of this cost structure. When you build a custom solution of your own, you don’t need to carry the burden of these overhead costs.
Some larger software vendors also dictate server and network topologies, requiring multiple training, quality, testing, and production environments. They require these environments for you to be “certified” or in compliance to obtain their product support. These requirements can make it difficult for organizations to optimize their infrastructure and can also contribute to higher operating costs.
Limited Access to or Ownership of Data
Who owns the data? This is a question you should ask any time you purchase a software product, especially if it’s a SaaS product. Your data might not be your data. Recent regulations like GDPR in Europe and CCPA in California offer protections for consumers, but they do little to protect business data. Read the fine print to make sure you understand data ownership when you purchase software.
Even if you do “own” the data with respect to packaged software, you need to understand how accessible the data is. The data in that system might be needed as part of a process automation or data analytics use case. If it is difficult or impossible to access, it will limit what you are able to with the data. These concerns don’t exist with a custom solution.
Features are “What’s Best for All”
New features need to consider the entire user base, not just your company. Considering the needs of all users drastically impacts what features get built and can result in watered down functionality that comes close to your needs but is missing key benefits unique to your organization.
High Integration Costs
High integration costs are not always a concern with packaged solutions, but you need to understand them. Before making a buy decision, understand their integration capabilities, whether they have an API available, and how robust it is. It’s also important to understand whether specialized knowledge is required that may be difficult to find in the market. Some software vendors will use integration as an alternative revenue source so there is an incentive for them to limit the market.
Long Cycle Time for Requested Changes
If you have a new feature you’d like to see added to a packaged solution, don’t hold your breath. The software vendors likely already have a prioritized backlog of other features that need to be developed. Your feature request may never even be developed.
Expensive to Customize
With many products, especially SaaS products, customizations are not even an option. When they are an option, they often require specialized knowledge that can increase development costs. However, the heavy cost of integration comes in the future when you try to upgrade the software and have to undo or redo the customizations you’ve built. Many companies end up several versions behind and risk losing product support because of their customizations – which then increases business risk.
Lack of Control Increases Business Risk
If you are running critical business processes using packaged software, you may be at the mercy of your software vendor. Consider their longevity and financial stability. Consider the maturity of the software or market. Many SaaS companies are barely more than startups. It’s not uncommon for companies to get sold, pivot their product, or even go out of business.
Possibility of Bloatware
Software products that have had the time to mature often have a robust set of capabilities. They often sell you expensive licensing plans that give you access to all that great capability. Companies often struggle to take advantage of all those capabilities, but they’re still paying the licensing fees. If you’re looking to solve a specific need, there may not be a licensing option that meets your needs. In that case, you will have to pay for software or features you’re not going to use.
Possibility of Vaporware
It’s not uncommon that a software company will pitch a feature that is half-baked or doesn’t yet exist. This is especially the case with early-stage SaaS companies, but I’ve also seen this from software giants when they market a new capability that’s lacking in key features. This can happen when they want to get market feedback and / or generate demand to drive further development. However, this isn’t always clear during the sales process, and you only find out after purchase that the functionality isn’t what you thought it would be.
Conclusion
Ultimately, most Build vs. Buy decisions are driven by cost, but cheaper is not always the lower cost option. Before deciding, consider the known and unknown costs of your decision. Upfront costs – like custom development (build) or implementation (buy) and ongoing costs like licensing and maintenance – can be estimated. Other hidden costs – like increased risk or lost efficiency – are harder to quantify. Deciding between different software options to enable and transform your business is tricky. It’s often subject to misconceptions, biases, and perceived risk. Therefore, it can be a subjective process.
If you are considering a build vs. buy decision, you might also be considering multiple packages on the buy side of the debate. It’s not uncommon to use a software selection matrix to make a decision more objective. Build is always an option, so I recommend adding it to your matrix to help make that decision more objective.
When done well, a selection matrix will include multiple criteria that are weighted based on their importance to your decision. Consider adding the topics covered in this blog to your decision matrix weighted by their importance to you. Then add additional criteria that are unique to your business needs. You might be surprised by the results, and you will definitely learn something in the process.
If you would like our input on your decision, contact us. Our consultants have many years of experience helping organizations make the right decision, and we’d be happy to help you.
