This is a million-dollar decision with 50-million-dollar ramifications. And, I will warn you upfront that this choice can cause anxiety, heartburn and insomnia. However, I can help take some of the guesswork and uncertainty out of the equation for you.
Making the decision to buy technology components or to build them yourself seems relatively straightforward. You are a high-tech venture and therefore you MUST make the technology, otherwise what is it that your venture does? Don’t fall into this trap. There is no reason, in this day and age of GitHub, that tech companies have to develop everything from scratch.
You’re in good company!
Many large and successful tech companies have paved the way here already, for example Google bought Android, Apple acquired Beats, and Cisco bought Meraki. These market leading tech concerns, by their actions, have given you permission to build on top of or license technology to spur and advance your own venture.
How do you decide which is best for you? Begin by thinking about three things: time to market, corporate resources, and core competencies. Weighing the complex relationship between each of these variables will lead you to the correct decision for your organization.
Time to market
First-movers have a great advantage over those that follow — consider Uber versus Lyft. If time to market is your primary concern, then purchasing a good base technology (or getting it from open source) and building on top of it will most likely yield product and venture results and get you to an MVP (minimally viable product) much faster than starting from scratch.
The process of acquiring technology and customizing it to form the foundation of a new solution is like editing an existing document. In most instances, it’s easier and faster to edit, then to write it from scratch, and the same is true for product architecture and design. If your team has some context to begin with in product development, your project will likely be completed faster.
Sometimes the underlying limitations of the base technology you select actually work to your advantage by reducing feature and scope creep. Once again, if time to market is your most important criteria, then build versus buy is pretty clear – buy. But, keep reading through the next two points to see if other considerations carry more weight for you.
Available corporate resources
Most organizations do not have enough corporate resources to achieve their set objectives, but they still have to deliver. Licensing terms for technology, especially foundational technology, can be pricey and onerous, which makes them less attractive. Costs and terms can be too high to make the proposition economically and strategically attractive. If this is true, then you would conclude that the right course of action is to build rather than to buy.
However, before you reach this conclusion I recommend you do an extensive analysis of the “true” costs of building the product within your venture and with your resources on hand. Be sure to include the fully burdened cost structure of employees working on the product, and the opportunity cost your venture is indirectly paying by having these resources work on this product instead of what else they could be doing for the organization.
Corporate resources can often push the buy versus build decision to the build column, but when making this decision, ensure that you’re including all costs associated with building the product from scratch internally.
Core competencies can often be very difficult attributes to assess. Nevertheless, this is an important factor in your build versus buy decision. You’ll want to ascertain whether your organization has the ability to build the product in the technologies you’ll be using for this effort.
Some organizations struggle because they have low proficiency in the areas they need to operate in. This can make the buy versus build decision lean toward buy. On the other hand, some organizations have such good core competencies on the technology stack that they will be using for development that they can often meet or beat their developmental milestones, which tilts the scale toward build.
As your organization becomes more experienced with the technologies in your stack and acquires expertise from the market with new resources, a greater skill set and familiarity, a build decision may make more sense. It’s also possible that the development of your technology is so advanced, that the only choice is to build it internally because the product doesn’t look like anything else in the market and only your team is capable of building it.
If you do start out buying your foundation, it may make sense to focus on building core competencies in your organization around those core technologies and look to potentially swing from buy to build over time as your organization’s capabilities slowly increase.
Based on a careful analysis of the three factors above, your organization will come to the right build versus buy decision that will form the foundation for developing your future products and services.
Like what you’ve read, or not? Have a question or a topic to suggest? Want to get another perspective on an issue or challenge you’re facing? I welcome your comments, feedback and insights below or feel free to email me here.
About this blog The goal of this blog is to share my experiences, to capture and reveal valuable insights, and to draw from my serial entrepreneur-ship through 6 ventures over the past 20 years. I have encountered many impressive entrepreneurs along the way and I hope to share our collective experience with you to help teach and perhaps motivate you to launch your own B2B or B2C enterprise.
© Jitin Agarwal – All rights reserved. This blog is property of Jitin Agarwal and leadingventuresblog.com. Unauthorized use and/or duplication of this material without express and written permission from this site’s author and/or owner is strictly prohibited. Excerpts and links may be used, provided that full and clear credit is given to Jitin Agarwal and leadingventuresblog.com with appropriate and specific direction to the original content. For this blog, in instances where other previously copyrighted content, trademarks or brand references are used and noted as such, the author disavows any ownership claim, trademark, copyright or intellectual property ownership of these items and they remain the property of their respective and original owners, their inclusion in this blog is merely for illustrative example purposes only.