Build Or Buy
Deciding Between Developing Solutions Internally And Acquiring Them From External Providers
Every product helps people accomplish certain goals by offering solutions to specific problems. At some point, product teams must decide whether to build these solutions themselves or buy them from third-party providers. Trying to solve every problem can restrict development capacity and reduce delivery speed. Alternatively, relying too heavily on external shortcuts can create long-term limitations. The most effective teams thoughtfully evaluate the implications of building vs. buying and strategically direct their efforts. The first step to making the right decision is understanding what each option really means.
Building A Solution
“Building” means creating a solution in-house using your own resources.
Building a solution offers much greater control and customization than buying one. It means designing it exactly to your specifications and preferences. However, the product team must do all the development work (discovery, requirements, coding, etc.) to release the solution. This takes up engineering capacity and reduces the ability to work on other essential product work. Additionally, if the solution does not work well further, resources must be committed to complete fixes and improvements.
When To Build Solutions In-House
In general, it’s helpful to look for the following signs:
The solution creates a core competitive advantage.
The customer and business needs are highly specific.
The teams need complete control over features, design, and functionality.
There is sufficient time and resources to develop the solution.
Engineering capacity is available for other critical development work.
The solution must provide unique capabilities missing from off-the-shelf options.
The solution does not involve a new, unfamiliar area (no steep learning curve).
The solution does not require specialized domain expertise.
The solution does not have any special compliance requirements.
The solution must connect with complex internal systems that cannot be easily integrated with third-party applications.
Buying A Solution
“Buying” means acquiring a solution from a third-party provider.
Buying an off-the-shelf solution is less resource-intensive than building one. It means you don’t have to create something from scratch. The product team only needs to work on integrating the solution into the product. This frees up engineering capacity to focus on things of greater value to customers and the business. The third-party provider has already built, tested, and validated their solution. If their solution has wide customer adoption, it’s a strong signal that it works well.
When To Buy Off-The-Shelf Solutions
In general, it’s helpful to look for the following signs:
The solution does not create any distinct competitive advantage.
The customer and business needs are flexible.
The teams do not need complete control over features, design, and functionality.
There is not sufficient time and resources to develop the solution.
Engineering capacity is needed for other, more critical development work.
There are multiple mature, cost-effective solutions available on the market.
The solution involves a new, unfamiliar area (steep learning curve).
The solution requires specialized expertise, which may be challenging to acquire.
The solution has special compliance requirements that are challenging to meet.
Why The Build Vs. Buy Decision Matters
As a company grows, customer needs and business needs evolve. When it gets to a certain size, it must be more deliberate about its investments (time, money, etc.). It has finite resources. Each commitment to building something reduces the resources available for building other things. It’s not always efficient or wise to build everything in-house. So, they must decide whether to build or buy new capabilities necessary to grow their product and their business. Many reliable, cost-effective third-party solutions are now available on the market. This means integrating an external solution is now a lot more viable than building one in-house (for many applications). Therefore, product teams must understand how to separate what must be built from what can be bought, so they can maximize value for the customers and the business.
Being the world’s best at something that our customers don’t care about is wasteful. As an alternative, we could outsource that (work) and have our engineers “move up the stack” closer to the customer and work on other engineering problems that the customer does care about.
— Mike Fisher, Moving Up the Stack
Build Vs. Buy Considerations
Recognize The Complexity
How hard is the problem to solve?
A startup’s success often hinges on its ability to identify, understand, and solve the underlying problem. Most engineering teams are quite capable. While they certainly can create solutions for many problems, it’s not always efficient to ask them to do so. Solutions that seem simple can involve hidden challenges. Similarly, third-party solutions that seem “perfect” can involve unforeseen limitations. Teams must map out the solution and its entire lifecycle—development, maintenance, updates, fixes, and scaling—to understand just how challenging the solution is to build or buy. They need to understand what is hard and what is not.
Additionally, when engineers have to build things outside their area of expertise, there can be a steep learning curve. They might not know all the challenges they might encounter. This makes it tricky to reliably estimate the effort involved in building a solution. It’s important to recognize problems that require specialized domain knowledge and expertise. It takes time to develop this. Third-party providers often have the necessary expertise because they have already explored the problem space at length and built a viable solution.
Evaluate The Needs
Customer And Business Requirements — What are the specific needs?
The solution must meet the requirements of all stakeholders. To do this successfully, product teams must first define their needs to determine what needs to be built. They must also consider how these needs might change long-term as the product, the customers, and the business evolve. This provides a framework to evaluate whether to build a solution in-house or buy an off-the-shelf one. Typically, third-party solutions have limited flexibility. However, for teams with highly specific requirements, building a solution in-house is the only feasible option.
When teams underestimate how specific their needs are, they buy solutions only to end up having to build costly, complicated workarounds. In the worst case, they might have to build the solution in-house anyway. When teams overestimate how specific their needs are, they build solutions that could easily be replaced by more reliable and less expensive third-party solutions. By anchoring their decision to clear, specific, and compelling needs, they can prevent over-engineering or overbuying. This ensures the solution creates real value for the customer and the business.
Timeline Constraints — How fast can you build a solution, and how long do you have?
When considering the timeline, product teams need to consider how long it will take to build a solution and how long they have to deliver it. In competitive markets, speed is always a priority. Sometimes, it may not be feasible to spend weeks, months, or even years building a solution — getting to market first may be more important. Buying an off-the-shelf solution can offer considerable benefits — it saves engineering time, accelerates time to market, and accelerates time to value. If there is an immediate and compelling need for a solution, it may be better to buy one instead of building it. Even with a talented team, building a solution will almost always take longer.
Compliance Requirements — What rules, regulations, and standards apply?
Some industries have strict compliance requirements. Getting things right matters because the consequences of non-compliance can be severe. However, it can be challenging to solve the problem and meet all the relevant compliance requirements. Product teams need to consider if they are willing to tackle bureaucracy, develop deep subject-matter expertise, and operate within strict constraints. If they are not prepared to handle this, it might be better to choose a compliant third-party solution to integrate instead. However, even if they choose to buy a solution, they are still responsible for verifying that the third-party provider stays compliant.
Understand The Value
Customer And Business Value — How much value does the solution create?
Core product features often directly impact the bottom line because these are things customers need and are willing to pay for. Meanwhile, everything else might not directly impact the bottom line because these are things customers expect but are not willing to pay for (or pay more for). So, it’s more productive to concentrate on building things with a greater return on investment. Trying to build too many things can dilute a team’s efforts and subsequently reduce the value they can create. Therefore, they must strategically invest in things likely to offer the greatest return.
Strategic Value — What competitive advantage will this solution provide?
Building a solution in-house gives product teams more control. They can enhance their value proposition and differentiate themselves by developing unique functionality in-house (via proprietary algorithms, innovative experiences, etc.). This is harder for competitors to replicate. However, if the solution addresses a problem that’s already been solved, there’s no point in reinventing the wheel. Therefore, product teams must consider whether building a certain capability really gives them a competitive advantage. If there is no distinct benefit to building the solution in-house, it’s often more beneficial to just buy instead of build.
Analyze The Costs
What is the total cost of building and supporting the solution?
When deciding whether to build or buy a solution, it’s important to consider the total cost of each option. The cost of a solution is not just the cost of developing and releasing it. It also includes the cost to support it indefinitely. Therefore, product teams must consider both short and long-term costs when deciding whether to build or buy.
Cost of Developing And Maintaining A Custom Solution
Product teams often prefer to build solutions because they have already budgeted for engineering time. Buying external solutions means spending more money. However, many teams underestimate the cost of building solutions in-house. Things can go wrong, increasing development costs. Even after deployment, there are ongoing costs for maintenance, updates, bug fixes, documentation, training, etc. These activities will continue to consume more resources. Costs also multiply when you need to deliver consistent experiences across platforms and devices.
Cost of Purchasing And Integrating An Off-The-Shelf Solution
The cost of third-party solutions can vary. Simple solutions (like access to specific APIs) can be relatively cheap, but complex solutions (like enterprise services) can be quite expensive. There are one-time costs (for setup, licenses, etc.) and recurring costs (for continued access). The product team must also contribute some resources to complete and support the integration with the third-party systems. Future changes could require more adjustments, meaning more costs. So, product teams must consider if the economics of buying a solution make sense in the long run.
Conclusion
The buy vs. buy decision is ultimately about strategically using resources.
Winning in competitive markets requires knowing where, when, and how to concentrate resources. The product teams must deliver value in the most efficient way possible. Sometimes this means building a solution from scratch. Sometimes this means integrating an external solution into the product. Every product decision has downstream consequences. The right choice depends on the immediate and long-term priorities and goals. Strategic decision-making creates greater efficiency and focus, ultimately helping companies achieve sustained commercial success.