How to decide to Build or Buy, now and in the future

Posted on March 16, 2024 • 12 min read • 2,352 words

Every engineering leader will face this question at every corner: Build it or Buy it?

Introduction to the “Build or Buy” problem  

The strategic decision of whether to build or buy is complex and multidimensional. Even how the question is presented can influence the outcome. To make an informed decision, it’s crucial to first comprehend the various aspects of the problem, the solutions landscape and to consider your specific position. Keep your team involved in the conversation as they hold critical knowledge. This will enable you to ensure that the decision is financially sound, aligns with the company’s overall vision and long-term goals and fits the technology strategy.

In this article, we will be looking at:

• Understanding the dimensions of the problem
• The importance of flexibility and how to achieve it through the dimensions and over time.
• The role of software architecture
• The Risks associated with slowly changing circumstances and how to mitigate
• Ownership and long term support
• The impact of the Human players and keeping folks engaged

Understanding the Dimensions of the Problem  

Business  

The business dimension represents what the business aims to achieve, how it fits in the market and informs the product roadmap which the team aims to realize with technology.

Product Strategy  

Hopefully following some market study and interviews with customers, a new product or feature is defined. There will be a choice to purchase an existing solution and integrate it into the company’s offering or to implement a solution in house (possibly a combination of both). We’ll leave acquisitions aside but similar reasoning applies.

Differentiator Vs. Utility  

In this dimension, we must determine how core this product or feature is to the strategy. Does this feature require proprietary know-how? Is it a capability that would make our customers choose our product over the competition?

To sum up: How does it differentiate us from other players?

For example, if you’re in the live event business, differentiators can be an assigned seating inventory engine, flexible product cataloging, a dynamic pricing engine.

Or is it something that is required, cannot be overlooked, but will not give you a definite win. That is, a utility. Electricity for example, but also, if you sell tickets, a database, cloud infrastructure, etc.

Frequency and Nature of changes  

Another consideration is the likelihood and amount of customization and modification which will be required within that scope as well as how involved those changes will be. The more changes, the more control we’ll need over the solution which could be a case for building your own.

This is a dimension that is related but orthogonal to the previous dimension. It is an expression of the natural complexity of most problem domains as you go deeper.

Lost Opportunities  

An in-house solution will take bandwidth to bring to life and likely significantly more resources to maintain than an off-the-shelf solution. These folks won’t be able to engage in other activities, explore other opportunities or develop other features. What else could you do with those resources?

Timing  

Time is another dimension to consider. There might be tactical goals that need to be achieved in the short to medium term, which can impact the solution choice due to time constraints.

Note that this timing dimension can go both ways:

You could be offered a beautiful “turn-key” solution but it requires you to align several departments on a common set of processes and tools, which will take time you might not have.

You could achieve a better outcome with a tailored solution but the lead development time is incompatible with your current schedule.

Finances  

Depending on the company’s stage, there might not be enough funds to engage with a ready-made solution. In such cases, a more humble implementation developed in-house might be necessary.

Or we need customer revenue and must invest in differentiators to unlock contracts and do not have the budget to invest in a better in-house solution.

Technology  

Implementation  

Depending on the tech stack of the solution and the available ways to integrate, the implementation could go from being a deal-breaker to a little maintenance overhead such as adapters and/or new processes and documentation. Be wary also of the marketing brochure claims of easy integration. Test in your context.

Architecture  

Whether it’s in-house development or an off-the-shelf product, the solution needs to fit the bigger picture. The alignment of the solution in terms of architecture will be a driving factor in the cost of integration with the rest of the product.

For example: an all GUI application lacking APIs will be at odds with a service based architecture. A customer service system should be interconnectable with the engineering ticketing system.

Operations  

Beyond the initial cost, the decision should consider the Total Cost of Ownership. Operations will factor in this cost.

Ownership  

Ownership should not be forgotten, even for off-the-shelf products. The product or feature will need a home. A team or someone who will perform upgrades, configure the system, maintain consistency, define standards and answer questions. It is important to make a clear determination of ownership based on domain, skillset and staffing.

Maintenance  

In all cases, there will be an additional maintenance burden on the team with the introduction of new functionality. The amount is likely to be less for an off-the-shelf product but you should evaluate your own situation. Consider also the benefit of having extra team members (the service provider’s team) partially working for you. Note that it comes with the possible drawback that the timing of their changes will not align with yours. In the end, you should consider how this adds up to your current Level of Maintenance Burden.

People  

The human factor is important. The choice of technology should be done taking into account the impact on the team.

Team Skill match  

In evaluating the approach, consider the skills and experience of the team who will have ownership. The impact will range from delay due to the natural learning curve to costly failures and architecture mistakes which could slow you down for months or years.

Skill and Knowledge Development  

Whatever solution is selected should, if at all possible, bring something to the team in terms of skills, knowledge, and experience. If not, the purchased solution should have standing in the market, granting the team some marketability. On the flip side, be wary of “Resume Building” decisions. The project will have to live beyond the tenure or attention span of those highly vocal and motivated individuals.

Staffing  

You might need to hire new folks to bring a specific skill set or level of experience to the team. If you have several teams, you might find folks with prior experience, interested in moving. Be ready to deal with team members deciding to depart due to the choices. This should ultimately not be the main driver for your decision but if it is a concern, you should engage directly with those folks to attempt to keep them engaged and have a backup plan as this could impact your project’s timeline.

The Role of Software Architecture  

Architecture’s role is to support the realization of the company’s strategic goals. It begins with a clear understanding of the company’s vision and objectives, which then informs the creation of a product roadmap, then mapped to problem domains and realized as solutions within those domains.

Taking a domain driven approach, the identification of the problem domains in scope is a critical step. It will inform the scope of the search for an existing solution but also help identify the constraints to satisfy so that the chosen approach fits within the existing system.

The understanding of those boundaries will also inform the definition of interfaces and contracts between the systems to control the cost of change in the future. You might want to start your journey by using an external solution but you know that you will want features beyond what that solution offers. Understanding the interface and making it explicit will allow you to control the cost of changing providers in the future.

These interfaces can often be informed by an analysis of available solutions in that space.

Software Architecture is effectively the set of all technical decisions made. Cost of change being the main factor to rank their importance. That cost of change should determine how hard you think about the decision at hand.

The Importance of Flexibility  

Instead of trying to guess too hard what the future could be like, be ready to “shift gears”. In a “build Vs. buy” context, this means that your decision has a lifespan. It will need to be reevaluated when new critical information becomes available. For that reason look for optionality as you evaluate your choices.

If purchasing a solution, place a premium on integration options: APIs, getting data in, getting data out, etc.

From the architecture and software design perspective, you can design this flexibility through techniques such as componentization and modularity. If you’re an adept of domain-driven design, you’ll look for bounded contexts.

From the people point of view, how many options do you have in terms of ownership? Support? What if the current owners get busy, who’s the backup?

Slowly Changing Circumstances  

The frog in the boiling pot  

Going back to the importance of placing an expiration date on the decision is to be able to react to slowly changing circumstances. Whether it is because the team’s makeup has changed, the technologies have shifted, or the maintenance has increased.

Clearly documenting the decision to “build or buy” then will provide valuable contrast when reevaluating the current approach later.

Sunk Cost Fallacy  

Another bias in play as circumstances change is the sunk cost fallacy, making it more and more difficult to change course as the investments in the initial choice pile up. More and more features, integrations and processes grow around the initial solution. They individually took little time to implement with the existing solution, but now that the solution is becoming less viable, those investments have led to a solution that is woven into the fabric of the business and hard or impossible to remove.

The world catches up  

There might be nothing wrong with your in-house implementation. There were no viable external alternatives a few years back when you started. But now, multiple open source implementations exist amd managed services are available.

Your code might be elegant and well tested but is it free of maintenance? At the minimum, libraries need to be upgraded to stay on top of security patches and compatibility with surrounding frameworks.

If it’s not core to your business, how about switching to an external solution? How long to amortize the initial transition cost? How much time would you claim back? What else could you do with that time?

Blood, Sweat and Tears  

The incremental investment has another effect which is especially difficult to deal with because of its emotional nature. As engineers invest more time in their code, some of them will develop attachment to their work. They will find reasons why you should continue to invest in a custom solution. They might be right, so you should listen. But be aware of the bias.

Continued Ownership  

Who will be responsible for the solution over time is a critical factor to consider. There should be a plan for long term ownership from the get go. Having the solution managed by the folks who need it is likely to eventually result in a poorly maintained solution as the team will soon need to tend to other projects and might not be available to assist other teams needing the solution.

The recommendation here is again to turn to your domain design and allocate the solution to the appropriate domain owner. This might require you to introduce a new team or widen the scope of an existing one.

Also consider the technical qualities of the solution as you would need to hire for it in the future. What would a new engineer gain by working with that solution? A proprietary tool using a proprietary dsl scripting is knowledge that is not very portable. It might be interesting initially but it’s not making them more marketable and it might be less attractive to new candidates.

The Human Factor  

Ultimately, the work will be performed by people and having them engaged is a big predictor of success. It is therefore crucial to involve the team in the decision making process. Look for prior experience, knowledge of the domain and maybe an existing lean towards a certain technology. Ask yourself: What’s in it for the team? A team with skin in the game will go the extra mile.

Each new project is an opportunity to improve the skills and knowledge of your team to everyone’s benefit. Building something will definitely be a learning opportunity but experience with an off-the-shelf solution or technology in a good market standing will grant the team some marketability.

The selected solution might impact people you hired for specific roles now at odds with the new tech. They might find themselves unable to be effective and you should have a plan to assist them with the transition.

Making your decision  

We’ve explored many of the dimensions to consider when deciding to “build or buy”. With that information in mind you are in a better position to make an informed decision.

Now comes the time of comparing the different solutions you have found. Build yourself a comparison matrix, a simple spreadsheet with rows for each use case and columns for each solution. Your in-house solution should be in the comparison as well.

Review the dimensions we discussed and think through your problem’s use cases for each dimension. Discussing with your team and writing down how each solution stands in each dimension.

The better choice should be clear now. Good Luck!