"If it isn't built here, it isn't %$&*!"

If I had a nickel ($1 with inflation) for every time I have heard this from development and engineering teams, I would be... well... not rich, but we could have a nice dinner! (Replace the word "built" with designed, engineered, or developed as interchangeable with build or built.)

It comes from an honest place of pride, ownership, and confidence of development teams, but can also be limiting for your organization, and an even bigger problem is the potential inefficient utilization of your valuable and often scarce development resources.

In today's business climate, budgets are tight, teams are smaller, competition is fierce, which makes it critical that you are maximizing the utilization of your resources and limited budgets. It gets even more critical for start-ups when you are trying to stretch out that Series A funding.

Should you outsource some or all of the work on a project? Should you OEM a product from another manufacturer? Or, should you develop that product entirely with your own team?

A great method of making this determination is a Build, Buy, Rent Analysis. Let's take a look at this analysis. This is also a method I would suggest as you evaluate every new project.

What is a Build, Buy, Rent Analysis?

It is a strategic framework used to decide the most effective way to acquire or develop a necessary component, technology, or entire product for a company's needs. It helps organizations weigh the pros and cons of different approaches to achieve their product goals.

• Build (In-House Development):
  • Explanation: This involves creating the product or component from scratch using internal resources and teams. It means dedicating your own developers, designers, and project managers to the task.
  • When it's suitable:
    • When the required solution is highly unique, proprietary, or provides a significant competitive advantage.
    • When there's a need for deep customization and control over every aspect of the product.
    • When the company has the internal expertise, resources, and time to develop the solution.
    • When intellectual property (IP) ownership is critical.
  • Pros: Full control, potential for unique differentiation, IP ownership, aligns perfectly with specific business needs.
  • Cons: Higher initial cost, longer time to market, requires significant internal resources and expertise, carries development risks.
• Buy (Off-the-Shelf or Acquisition):
  • Explanation: This involves purchasing an existing solution, software, OEM product, or technology from a third-party vendor. This could range from buying a commercial off-the-shelf (COTS) software product, to purchasing and rebranding an OEM product from an OEM manufacturer, to acquiring another company that has already built the desired product or technology.
  • When it's suitable:
    • When a suitable solution already exists in the market that meets most of the requirements.  “Why recreate the wheel?”
    • When speed to market is a priority.
    • When internal resources are limited or lack the necessary expertise.
    • When the core competency of the business is not in developing that specific solution.
  • Pros: Faster deployment, lower initial development costs, proven functionality, reduced risk (if the product is mature).
  • Cons: Less customization, potential vendor lock-in, reliance on external roadmap, might not perfectly fit unique needs, ongoing licensing/maintenance fees.
• Rent (Software-as-a-Service - SaaS, Licensing, or Distribution of a 3rd Party Product):
  • Explanation: This approach involves subscribing to a service or licensing a technology that is hosted and maintained by a third-party provider. Users access the functionality as needed, typically on a subscription basis, without owning the underlying infrastructure or software. For hardware projects, may also involve distributing a 3rd party product that fills the product requirements needed.
  • When it's suitable:
    • When a ready-to-use solution is needed quickly for non-core functionalities.
    • When scalability and flexibility are crucial, allowing for easy adjustment of usage based on demand.
    • When minimizing IT infrastructure and maintenance overhead is a priority.
    • When upfront capital expenditure needs to be low.
  • Pros: Low upfront cost, rapid deployment, scalability, no maintenance burden, automatic updates.
  • Cons: Less control and customization, dependency on vendor for uptime and features, data security concerns (depending on the provider), ongoing subscription costs can accumulate over time.

How the analysis is done:

The "build, buy, or rent" analysis typically involves evaluating these options against various criteria, including:

• Cost: Initial investment, ongoing maintenance, total cost of ownership (TCO).
• Time: Time to market, development timelines, deployment speed.
• Resources: Availability of internal talent, infrastructure, and expertise.
• Control & Customization: Level of desired control over features, design, and future development.
• Risk: Development risks, integration risks, vendor stability risks.
• Strategic Alignment: How well each option aligns with the company's long-term strategic goals and core competencies.
• Competitive Advantage: Whether the solution provides a unique edge in the market.

By systematically evaluating these factors, product teams and leadership can make an informed decision that best supports their product strategy and overall business objectives.

OK, so now you know what a Build, Buy, Rent Analysis is…now what?

This is where you now need to use your analytical skills to look at all of the data along with all of the current factors like cost, time, resources, etc. to lead you to the decision on which approach to take with the project you are evaluating.

A few additional comments on the analysis

• What is your “secret sauce,” core technology, or IP that you own? You should ALWAYS own this, and the development of that technology should always be a build item. One of my mentors frequently said, “You shouldn’t rent vital organs.” Your “secret sauce,” core technology, or IP is a vital organ. NOTE: this may only be one part of your code, an algorithm, or specific hardware function, so other parts of the whole project may still be up for assignment to Buy or Rent.
• The determination of Build, Buy, or Rent should not be an emotional decision. It is a pragmatic decision based on facts, realities, and need. It often requires a shift in common thinking for development teams. That part is emotional for the development teams but can be overcome with good communication.
• The overarching goal of a Build, Buy, Rent Analysis is to more efficiently utilize the resources you have and supplement those resources to meet the company’s goals by delivering the right products and services at the right time and at the right cost to delight customers.

Need help with your Build, Buy, Rent Analysis?

While I mentioned above that the decision to Build, Buy, or Rent should not be emotional, I find that it often becomes emotional. This is when an independent and objective viewpoint can be very beneficial.

At Williams Apex Advisors, we can work with your teams to ensure that we collectively take into consideration all of the data and factors to help the team reach the best decision. Did you catch that not-so-subtle point, “help the team reach the best decision?” If the decision is made without the team, many times that project will fail. I won’t get into the psychology of team dynamics in this blog, but in order to succeed, the project needs to have been fully bought into by the team; otherwise, when it fails, the “I told you so” voices make themselves heard. This can derail future decisions with the “remember when?” voices.  

Let us help you with your next analysis. Our proven and pragmatic approach can help your teams reach the right decisions. Find out more about this service, which is part of our Product Roadmap Refinement service here.