When to Build vs. Buy
I had been lucky enough to get to work on a diverse variety of business models and approaches to solving problems over the past 20 years. For most of the major initiatives these companies face, the stakeholders must usually choose between the following:
- Do it yourself
- Get some help
This is often referred to as a Build vs. Buy scenario.
Building is when a company decides to use existing resources (or bring on new resources) to create some thing or acquire the capability it needs.
Buying is when a company looks for outside help to fulfill a need. This may not necessarily involve spending money.
Basic Build vs. Buy Categories
In a perfect world, I see 3 different categories for Build vs. Buy scenarios
- Build only Key Items
Buy/Automate commodity business processes; build when you're dealing with the core processes that differentiate your company.
In many cases, there may not be an option to buy something to adequately accommodate the differentiators. There is a reason most of the Financial Services firms employ large custom development teams, as their needs are often highly unique and complex.
In addition, a company's Intellectual Property is likely something that makes its business unique and it is not something it would want to share with competitors. If it builds the key software and processes internally, then they have greater control over it.
- Buying Something Not Easily Built
There are opportunities where it makes sense for companies to look to Buy key differentiators rather building them.
Market Share is certainly a key differentiator to many businesses. While it may be feasible for a company to gain market share in established verticals (red ocean) through quality offerings and execution, it usually takes a long time to gradually win market share from competitors. So it sometimes makes sense to buy market share - via an acquisition or partnering relationship.
In the past 2 years, Facebook bought Instagram and Microsoft bought Skype for billions (at multipliers far beyond there projected earnings). Facebook and Microsoft each have tremendous resources and internal talent, and probably could have rolled out competing offerings to the ones they bought. But they decided acquisition and market share growth was key. - Supplementing the Build strategy by Buying (hybrid)
Buying may be a great way to initiate growth and/or progress. It sometimes makes sense to buy components of the solution to make the build approach move faster and in a more stable way.
When buying a company, the brand, capital, intellectual property, market share, and resources (including employees) all come with it. In the tech world, I read about Acqui-hires, where companies are bought as a way to acquire talented individuals to supplement their own teams.
Another example may be to bring in a Subject Matter Experts (SME). While I know many people choose to design/renovate parts of their homes, supplementing the process with a quality architect often leads to better results and fewer overages.
A third example may be to use/review as a commercial off the shelf (COTS) software as a starting point for your application. I'll include open source when referring to COTS for the purposes of this post. In many cases, the software’s developers have spent time considering the problem and likely have accounted for valid use cases you may not have considered. Looking at the way different ecommerce represent products, product variants, and promotions in their data models (databases) can be a great help even when you choose the build option.
Since these decisions are always driven by some business initiative, it is not so easy to simply lump your problem into one of these buckets. You are going have lots of cases where it looks obvious on the surface whether to simply build or buy, but there is more to consider (detailed in the next section):
Factors to consider in the decision
Let's assume there is problem you need to solve and there is both a potentially viable Build and Buy option.
The following factors (from http://www.nevo.com/our-knowledge/whitepapers/BuildVsBuy.pdf) I've used for decisions concerning software platforms, but many apply to the other categories:
- Significance
The level of importance the problem this decision needs to solve as compared to other competing initiatives.
- Coverage
When considering buying a COTS software, you need to consider the gap between its functionality and your requirements.
- Direction
The solution needs to support the planned future direction for the initiative and company. Consider the flexibility, maintainability, and extensibility the application. - Total Cost of Ownership (TCO)
TCO includes not only the cost of acquisition, configuration, and customization, but also the ongoing support, maintenance, and evolution of the application. It is quite common for lifetime costs to dwarf acquisition costs. - Scale
Consider the application’s ability to handle the current and foreseeable future scaling requirements. As the business need grows, how will the application perform and how will the cost structure (licensing) grow?
- Timing
Conventional wisdom held that implementing a packaged solution was faster than custom development. As one might expect, this is an oversimplification. The process of installing, configuring, customizing, and completing data conversion for packaged solutions routinely involves tasks that are as complex and extensive as custom development, with far less flexibility in phasing and timing.
COTS packages may offer greater predictability with respect to implementation time, but that is largely a reflection of the restrictions they impose on capabilities and flexibility - Standards
Standards may be the most important criterion of all. COTS vendors market the notion that the cost of software development can be spread across that a large user community, thereby reducing the cost to each individual customer. - Volatility / Risk
By “volatility” we mean the frequency and complexity of new releases. Greater volatility means increased support and maintenance costs, since a common characteristic of packaged solutions is that customers must test, integrate, and install each release, whether it contains desired enhancements or not.
Each new release presents substantial risk to the stability and availability of the system to users. The burden of validating content, testing. - Business Process
While it is common for packaged solution vendors to claim complete flexibility in configuring their solution to meet existing business process this is rarely the case. Most often client organizations are urged to modify their business practices to conform to the range of choices that the package offers.
Scenario when I Built
For a few years I looked everywhere for a site where I could find accurate market values for sports cards. While I could find companies offering a retail suggestion (like blue book for cars), there wasn't anything that provided guidance on market values in close to real time.
I looked into quite a few platforms and frameworks for general price determination, learning from some of their principles. I decided that none were offered the functionality I required to specifically support this vertical, so I decided to develop my own. The platform went on to become SportsCardDatabase, and has 1000's of registered users visiting daily.
Scenario when I Bought
When I wanted to add a chat function to one of my sites I was faced with this scenario. My first gut instinct was to think about how I wanted it to work. I quickly surfed around for some Jquery plugins, started mapping how I could persist the data, designing some interfaces for RESTful services. I figured it would be a fun learning experience that would probably eat up a few weeks of my time.
Before writing any actual code, I did a few quick searches and found an affordable package that met most of my requirements. In a few hours of playing with the demo, I satisfied the key enhancement I required - integrating the chat login with my site's member accounts.
As much I thought it would be fun to build a chat platform, that is not the key differentiator for my business. I knew that buying and implementing the package made complete sense.
About 2 years later, I revisited the decision when I had requirements that the package I had bought could not accommodate. The first thing I did was to look to "buy" something. I was able to quickly find a free open source alternative that was more robust and user friendly than my previous package, and that is what my site uses today. I love the fact that I have the source code, so I was able to make some small enhancements that are specific for my site's requirements.
Scenario when I both Bought and Built
About 7-8 years ago, I took on a consulting project to build a web site for a client. I had the ability to design the site and code all the functions required, but I wanted to make the best use of my time and the client's budget.
Instead of spending the considerable amount of time trying to sell a creative design (not really my strength), I decided it would be a good idea to let the client choose the design from a choice of templates. I directed him to templatemonster.com, and he was able to select a design he liked in a day (for around $100). If I was to try to design something for him, it would have taken many iterations of proposing design ideas and review - and certainly cost more than $100.
I used that design template and was able to spend all my time building his site - the part I liked most. The project came in below the estimated budget, and ahead of schedule.