Understanding Build vs. Buy: 2 Scenarios

ionicons-v5-kBy TyJune 27th, 2022

Build vs. Buy is a common colloquialism in technology companies today. It gets thrown around pretty regularly, so it’s worth having an understanding of what it means, how it applies to your organization, and how to navigate toward a solution. Let’s take a deeper dive into what it means, and when it becomes relevant to companies and organizations.

What is Build vs. Buy

When a technologically capable company encounters a problem that requires a software-based solution, they are faced with a choice:

  • Do we build the software ourselves? Or…
  • Do we purchase something that’s already built

There are 2 common circumstances in which stakeholders or technical leaders for companies encounter this question.

Scenario 1: We have an internal problem or process that needs software

As organizations grow in size, so do their logistical problems. This may seem elementary, but many business people forget, or fail to realize that the problems of a Fortune 50 organization are wildly different, even than a 100 person startup.

Problems like staffing, payroll, benefits, facilities, equipment, and the like become significant challenges when an organization employs 10,000 or more people. Logistically, it becomes impossible to handle these issues without the implementation of some type of software to manage them.

In large, or growing, organizations, understanding how to better manage these problems of scale and implementing more efficient, cost effective systems are what takes up a large portion of upper management's time. This is where Build vs. Buy becomes a common discussion area organizationally.

Determining Build vs. Buy for Internal Business Software

There are a number of questions to consider when trying to determine Build vs. Buy for internal business processes.

How immediate is our need?

This is a big one. If your need is immediate, it’s likely that you’re not going to have the time to build a completely custom solution from scratch. In this case, you’re going to want to pay very close attention to whether or not a prebuilt solution can be customized to your particular use-case, or whether you can adapt your need or process to fit a pre-built solution.

Is there a solution that fits our specific needs?

If your needs are fairly generic, it’s likely that you will be able to find a software solution that can easily solve your pressing business problems. However, in many cases, especially in larger, mature organizations, needs can become very specific, and it can be difficult to find a packaged solution that fits your unique and specific use-cases.

Is there a solution that fits our budget?

As we all know, companies, and departments within companies operate on specific budgets. When trying to find pre-built software solutions, it’s important to do your research and due diligence, so you can fully understand the cost implications of implementing a solution at scale. If the number of users or stakeholders who are going to interact with your new software is low, you won’t likely encounter many budgetary issues. However, if you’re rolling new software out organization-wide, you’ll need to carefully consider the total cost of implementation.

How difficult is the solution to deploy in our organization?

No matter the scope of new software, or whether it is built in-house or is an out-of-the-box solution, there is going to be a cost (time cost and true cost) of deployment. Software, whether custom or not, must be adopted by your internal user base. This could be as simple as a tool tip guide in software, or a short video training series, or as complex as IT integrations and full-scale individual user training. The best strategy here is to examine potential solutions by estimating the cost in time, and the cost in dollars, to deploy the software in your organization.

Will the solution scale with our organization?

Outside of cost, any software solution you’re considering needs to be able to scale with your organization, and the organizational problems it’s trying to solve. There is a massive difference between deploying software to 100 people, or to 10,000 people. You need to ensure that your new software solution can handle the load technically without crashing, but also from a User Experience perspective. If you’re implementing a solution you plan to scale up in your organization, remember that introducing poor, slow, clunky user experiences is going to impact your bottom line in a very real way, simply by forcing your employees to take longer to perform a task.

Scenario 2: We want to take a new (or competitive) product to market

A second scenario common to larger technical organizations is the desire to bring a new product to market. This is common in established technology companies, who have brought one or more popular products to market, and are now focused on expanding their market reach, increasing customer engagement and NPS, or optimizing per customer revenue.

As an example, let’s look at a well established company in the medical technology space: Salesforce. Salesforce has been around a long time, and is fairly well established in CRM (Customer Relationship Management) for Healthcare and Life Sciences with their HealthCloud product.

One issue Salesforce may be facing as a larger company is that cloud computing, in particular video streaming and storage, has become more affordable in the last five years, which has given rise to more competitive startups. These startups are starting to take a different, more personal approach to patient management by applying live streaming to Doctor / Patient relationships.

Additionally, with the mainstream support of speech to text transcoding, natural language processing, and AI/ML driven sentiment analysis engines, doctors can gain more insights into their patients overall health, and self-perception of health.

Salesforce understands this transition, and also has a deep understanding of all of the underlying technologies, being a technology company themselves. However, Salesforce also understands the value of being first and largest to market, and may be willing to invest a good deal of money to capture market share of this new emerging market quickly.

Determining Build vs. Buy for Taking a Product to Market (GTM)

Determining Build vs. Buy for going to market with a new software product can definitely be more complex than solving an internal business problem, but there are a few points that can be a guide-post for decision makers.

How quickly do we need to get to market?

Needing to get to market can be a big driver of a software acquisition decision. In today’s tech landscape, companies move furiously in their Go To Market strategies, and keeping up (or staying ahead) can create a lot of positive pressure. When feeling that pressure, it’s important to keep your head, and realize that acquisitions don’t always result in faster market releases. More often than not, even successful purchases result in employee exodus and myriad other issues that prevent a successful launch.

Will acquiring get us to market any faster, taking into consideration transition time?

To that point, even in successful acquisitions there is going to be a transition period where both parties adjust to the new partnership. This is why we often see companies that, once the paperwork is finalized, do little to nothing on the surface to incorporate the new acquisitions into their existing environment. Let’s face it, corporate and startup cultures are wildly different, and while some people adapt and appreciate the stability a large corporation can offer, others are reluctant to change.

What is our acquisition (or build) budget?

This should be self-explanatory, but you need to have a reasonable gauge of what the value of entering the new market or environment will be to your organization, then use this estimate to determine what you should be willing to spend to enter the market. Lean into being extremely conversative, always orienting yourself around a worst case scenario. If the acquisition (or build) doesn’t make sense in what you think a reasonable worst-case scenario would be, drop it.

Are there any reasonable acquisition targets in the market?

A reasonable acquisition target, in this context, is a business that:

  • Has meaningful market share for your target demographic
  • Would entertain the idea of selling at your budget
  • Has adequate user engagement or NPS
  • Could theoretically pass legal and technical diligence

If you can’t find any candidates in your market, it’s likely you’re going to be building software.

Both Scenarios: Estimating a Software Build Cost

Remember, Build vs. Buy is a comparison. So far, we have discussed a bunch of Buy considerations, however, in both scenarios, we need to establish our critical comparison point: What would it cost to Build?

This is where many organizations fall apart. Estimating the cost to build software requires a couple of very important components that can be non-trivial for managers to assess. The basic components of estimating software are pretty straightforward:

Seems simple at first glance, however, the complexity begins when you start trying to guess at things like Resources and time. How many engineers do you actually need? What other staff members will be required? How long will it take them to build it? Is that a reasonable amount of time for what I’m trying to build?

Answering these questions requires a basic understanding of two concepts in software engineering called Velocity and Story Points.

Story Points

Story points are nothing more than a number applied to a body of work. Larger bodies of work get larger numbers, and smaller amounts of work are assigned smaller numbers. There are many different scales of story points, however, we prefer the Fibonacci scale for our projects.

To estimate the size of any given software project, we break the project down into stories (or small bodies of work), and at least 2 experienced engineers assign each story a number of points on the Fibonacci Scale (1, 3, 5, 8, 13, 21). If a story is at or above a 21 in point value, it needs to be broken down into smaller bodies of work.

Here is a quick example:

  • Task: Change the text on a button from Submit to Go
    Points: 1

  • Task: Implement Facebook authentication
    Points: 8

Tools for estimating Story Points can be as complex as custom software like JIRA, or as simple as typing it up on a spreadsheet.


Velocity refers to the average number of points an average software team in your organization can complete in a given sprint cycle. Typical sprint cycles are 2 weeks, and your velocity will vary given the size, experience, and organization of your particular team.

There are no hard and fast standards for velocity, because velocity is a form of self measurement, like timing your own freestyle swimming speed.

Putting it all together: A Reasonable Estimate

Now that you have an understanding of Velocity and Story Points, you can start breaking your software build down into tasks. There are good and bad ways to do this, so be sure to check out how to effectively spec software.

Let’s pretend for a moment that you have developed your full spec, and have estimated your build at 1,248 story points. Given the average engineer in your organization completes 20 story points a week, that would be 62.4 weeks for a single engineer to complete the project.

If you want to launch within the next quarter, you would need to hit 104 story points per week, which means having 4-5 engineers on the project. Now, you can start effectively estimating Resources & Time:

From here, simply multiply your cost per hour for each type of team member, and you should have a reasonable initial estimate for what building your software will cost.

The Rule of 2x

There is one word of caution… view this number as your starting place.

One of the issues with engineering, and invention in general, is that it is always to some degree experimental. You don’t know what you don’t know, and issues always arise. Issues can be any number of things from tasks being more complex than originally estimated, 3rd party services not playing nice, or even people simply becoming ill and missing work.

To account for this, most tenured product managers and engineers follow the Rule of 2x… take your initial estimate and double it.

This may seem crazy at first glance, but trust those of us who have been doing it for years and years. A project costing 2 or more times as much as originally estimated happens so often in building software, that if you can’t afford to double your budget, you probably need to re-evaluate the validity of your project and what you’re building.

Subscribe to 🎉💪 content!

Get our tech articles once a week, free of spam.