As tech executives, we face lots of technical decisions every day. One of them is Buy vs. Build. It’s an easy or hard one depending on your success book before. If you come from a traditional company or have a proven record in digital transformation, you would love integration-oriented architecture, which easily glues multiple systems with a “one-time” budget. Then “Buy” is the default answer for you. Otherwise, if you grew up in a startup tech company or climbed to a high ladder in successful tech companies, “build” is in your gene as these company pays lots of money to maintain high-capability tech teams and care more about IPs. However, even tech company builds the majority of features by themselves. They still face another kind of buying, named “open source”. Let’s call it Borrow. So, the discussion is BBB – Buy, Build, or Borrow.
To clarify the understanding of Buy, Build Borrow, we list the definition and pros/cons here.
- Buy. The company deploys the usage-based Saas Solution or one-time on-premise application through the integration layer. The Pros are it leverages the best solution in each function and sub-domain with limited integration effort, which reduces time-to-market. The Cons are it requires costly customization to meet business requirements/changes, and operation cost is high as you cannot fix the root cause once and for all due to lack of source code.
- Build. The company hires a highly capable engineering team to develop the application/web service system from the ground to meet business requirements. Pros, fully customized and fit the business perfectly. Cons, high cost and long development time.
- Borrow. The company hires a small engineering team to customize a mature open-source project to meet the business need. Pros. fully customized and fit the business, acceptable cost and time on development as open source project is mature. Cons. The high-capability engineering team and domain specialty.
Buy, Build and Borrow Comparison
Before we compare three choices, I would like to step back and revisit the whole picture. Why do we need to make the decision? A company’s fundamental is looking for profit to grow the business (let’s exclude the non-profit organization). Financial profitability is the top goal, and the technology must align and support this goal – no matter you sell the technology directly or leverage technology to run your business. Talking about the profit, it always makes us think about revenue and cost. On the revenue side, we could focus on exclusive revenue (which only you have or you have the advantage) and operational revenue (routine business which requires stable operation). On the cost side, we need to consider development costs and operation costs (including stability, nobody wants a profitable business broken every week). Now, we have four dimensions to compare three choices – exclusive revenue and operational revenue (the higher, the better), and development and operation cost (the lower, the better). Before we dive into the comparison, the following formula is just a mental model tool for you, but not a final decision, as each business is unique.
| Buy | Build | Borrow | |
| Exclusive Revenue | Low. The company brought an out-of-box solution, which is available to everyone. | High. The company has full IP, which is exclusive to other competitors. | Medium. The open source is available to everyone. However, the customization fits the business and has the potential to contribute back. |
| Operational Revenue | Low. The system stability depends on third-party infrastructure, as the software is a black box, fundamental default may not be fixed immediately. | Medium. Full code control could increase the system stability as the company could fix the root cause. However, due to resource limitations, some bugs will be postponed. | High. An active community could fix high-severity and minor bugs through crowdsourcing. A low-defect system increases stability. |
| Development Cost | Low. As the software is ready to use, it accelerates time to market and reduces development costs. | High. It’s a time-consuming project to build everything from the ground and very costly to hire a capable engineering team. | Medium. The primary functionality is available to use with best practice guidance. The add-on work is customization and configuration. |
| Operational Cost | High. Generally speaking, you have to hire a third party to operate the software or add new features, which is very short-term and costly. Sometimes, the expert is hard to hire | Low. It leverages general technology with a bigger talent pool | Medium. A middle-size talent pool compared with packaged software and coding language, but somehow expensive if the domain is hot. |
Additional things to think about.
Four dimensions just provide a thinking logic to quantify the evaluation. However, more factors are unable to quantify but critical to the decision.
- Company Stage. Time to market and budget are two essential parts to consider. If the company needs to launch features fast to acquire the market share, taking a long time to build it may not be efficient. However, if the company doesn’t have the money to maintain a competent team, it’s not good to go with build or borrow.
- Hiring and retention. As a tech organization, hiring and retention is the most expensive and challenging part. How could you find the right person with a reasonable talent pool? How could you keep them with more challenging and exciting tasks? Borrow has the advantage as the community has trained enough talent, but it’s hard to maintain them as more attractive jobs.
- IP and public image. Is the company going to file IP and protect the core value? Does the company want to give the public a tech company impression? Build could help with IP. Borrow could weigh on public image.
There is no one to fit all solutions to choose from, or even the right decision will be eroded after several years. The tech executive needs to revisit the decision every year or three years to make a reasonable adjustment.