Introduction

There are a variety of instances where teams encounter the Build vs. Buy dilemma, but all of them ultimately involve weighing the time of your team to build and maintain a custom solution over purchasing and implementing off-the-shelf software. 

The answer to the build or buy question is generally not whether your company has the capability to build something – it’s about evaluating the time, cost, and control tradeoffs associated with pursuing a custom implementation. An in-house solution can often seem like the most logical solution as it allows you to have full control over the end-user experience, but buying ready-to-use software heavily reduces your company’s need for design, development, QA, and maintenance costs. 

Given the large number of factors to factor into the choice, there is no definitive answer for whether you should build vs. buy. This in-depth guide will help you understand how to evaluate the decision, explain the circumstances where it makes sense to pursue each option, and help you determine the best path forward for your team.

Reasons to pursue an in-house build

Point solutions target pain points that are common across many businesses – for example, Customer Relationship Management (CRM), Enterprise Resource Planning (ERP), and accounting software. So, if you’re looking to solve a relatively unique problem, finding an off-the-shelf solution that fits well with your existing platform and workflows may not be possible.

3rd party platforms also likely won’t be a good choice if the pain point is in an area that changes constantly due to business or customer needs. This is because the solution will require constant updates, and off-the-shelf solutions generally aren’t set up to accommodate feature changes for a single customer. If solving the problem will also involve using many different vendors, you should also factor in the effort required to manage multiple applications and integrate the disparate systems if that’s required for your use case.    

Even if a 3rd party vendor exists that fits your use case (and may allow you to implement a solution more quickly), there are several reasons for pursuing a custom build. These include: 

1. Wanting full control over all the systems that involve your code’s execution – this is especially true when the issue at hand is not isolated and will affect many functions across the company/product, or you have demanding SLAs that cannot be met by a third party
2. Inability to buy services without a lengthy procurement process
3. Discomfort with relying on a service that isn’t open source, or not finding a vendor that meets the security requirements your business has
4. Tight budgets in a situation where 3rd party solutions are extremely costly, and you have the resources for an in-house build are readily available

To summarize, the main benefits of an in-house build are that you can customize the solution exactly to your use case, constantly update the software to fit changing requirements, and avoid 3rd party vendor fees. The primary drawbacks are that implementation will typically take longer, opportunity cost of features you could have built with the resources you spent, and needing to allocate ongoing maintenance costs. 

Reasons to buy a 3rd party solution

In a survey on global outsourcing in 2018, Deloitte found that 90% of organizations are considering or adopting cloud solutions they cannot quickly build on their own to gain a competitive advantage. Their 2020 survey showed the trend continuing, and staying agile while reducing costs is the top priority for companies around the world. 

If the feature you’re evaluating either building or buying is not part of your company’s core competency, costly to build, and is fairly isolated in your product, exploring if a ready-made solution solves your problem should be your first step. Purchasing an off-the-shelf solution allows implementation to be done much faster, letting your team focus on launching features that add value for your customers. Especially for complex features, the opportunity cost of pursuing a custom build can be significant. For companies that are quickly growing and innovating, spending time on software that could be purchased from a 3rd party takes away valuable engineering time that could be spent elsewhere.

Another factor to consider is how the timeline requirements and internal resources available will affect the quality of your initial feature launch. In certain cases, while it can only take a low amount of effort to release a basic version of the feature, missing key aspects can greatly affect your customer’s experience. This can result in product teams choosing to skip components to accelerate launch times, only to be forced to add them back to the roadmap after being bombarded by customer feedback. Months after launching, engineering teams are still committing additional resources to improving it – whether it be to improve stability, scalability, or user experience. This scenario is much less likely to happen with a 3rd party vendor whose focus is the feature in question, as they’ve already built out a robust version and are continuing to devote all of their resources into releasing updates and improving their product over time. 

While off-the-shelf solutions come with a fee, in many instances the price point is substantially less than the resource cost required to build your solution in-house. If the feature you are looking to integrate also gives you additional revenue opportunities, the faster launch time of a 3rd party solution can also cover the fees involved. 

Making the Build vs. Buy decision

After understanding the general pros and cons for building software in-house or purchasing an out-of-the-box solution, filling out the following worksheet can help you scope out the requirements for an in-house solution. This covers some of the key considerations your team will need to weigh against which can give you clearer direction on whether it makes sense to invest in a 3rd party solution. 

After scoping out your specific case, consider the following factors: 

• Your available resources: Who can you assign to deploy the solution? Do you have design, QA, and engineering teams readily available?
• How quickly the problem needs to be resolved: Is this blocking an important feature launch? Is it critical that a solution is implemented ASAP?
• Cost of external solutions: How much do you have to pay for 3rd party software solutions? Is that less than the internal resources required to build a solution?
• Customization & scalability: Are the off-the-shelf options customizable enough to fit into your use case perfectly, along with future use cases you may expand into? Are the 3rd party solutions built to scale well if you add substantially more users, larger files, etc.?
• Security: When choosing to buy a solution, security is largely handled by the vendor company. Depending on the use case, you may be sending sensitive information which is stored on their servers. In instances where the security needs are high (e.g. PHI is involved), a custom build may be forced if no vendor can be found that meets those requirements.     
• Maintenance costs: Even after an initial build, solutions will require dedicated resources for bug fixes, performance, and ongoing QA. When using a vendor, cost of maintenance will typically fall on them. How much maintenance will the system require, and does your team have the capacity to support ongoing updates?
• Budget: What’s your overall budget? Calculating the appropriate price point varies significantly depending on the functionality you’re trying to solve. Solutions that are expensive at face can be cost effective depending on how much time it saves your team and the business value unlocked to have a solution in place sooner.

Conclusion

When time and resources aren’t constrained and stakeholders, designers, and developers are able to have in-depth planning conversations to implement a new feature, building a custom solution can be a great choice. If your new feature is relatively isolated in your workflow, isn’t part of your core competency, resources are limited, and launching quickly is important, going with a 3rd party vendor will likely be the better choice.