When you are building high a tech product, a solution or a services company, the decision whether to buy technology products or to make them seems straightforward. You are a high tech company; therefore, you must make the technology. Don't fall into this trap. There is no reason why high tech companies, large and successful ones have paved the way here (Cisco, CA, Microsoft), can't profitably build on top of technology that is purchased rather than build it from scratch.

The key factors to consider when contemplating the buy vs. build decision are as follows: Time to Market, Corporate Resources and Core Competencies. Weighing the complex relationship between each of these three variables will lead you to the correct decision for your organization and the respective technology your looking to build. However, be forewarned usually you can only successfully manage two out of the three variables. You can most likely achieve getting a product out on time and assuring that your organization builds the core competencies desired, but that will probably require a liberal usage of corporate resources. Almost never can you successfully manage ALL three of the variables.

Time to market, the first criteria to consider, is a singular mantra for some organizations. In the majority of cases, in the buy vs. build decision, if time to market is your primary concern then purchasing a good base technology and building on top of it will mostly likely yield results faster than starting from scratch. The process of acquiring a piece of technology and then customizing the basic platform to form the foundation for your solution is akin to editing a document. In most instances, it is less time consuming to edit than it is to write, this is similarly the case with product architecture and design. In development, if you have some context to start from your more likely to get a product out the door faster. If for no other reason than the flexibility available to you to customize your platform is limited by the capabilities of the base technology, which essentially has the effect of creating scope and feature creep barriers. These two are often the biggest reasons why products don't get out the door and are much more likely when your starting from a blank slate, rather than purchasing an existing set of technologies. Therefore, if time to market is the variable most relevant to your organization, then look hard to acquire a set of platform technologies and then building upon it, rather than doing a clean room development project.

The next criterion to consider is the availability of corporate resources. There isn't an organization that has enough corporate resources to achieve its set objective, but you still have to deliver. The buy vs. build decision is a bit more complex to make when considering this variable. Typically, the licensing terms for technology, especially foundation technology, are quite expensive. These costs can be so high that acquiring these technologies might make the entire concept economically unattractive. This would then lead one to conclude that if corporate resources are a primary constraint then the right course of action is to build rather than buy. However, before you reach this conclusion do an extensive analysis of the "true" costs of building the product with your resources at hand. Your analysis of true costs needs to include not only the fully burdened cost structure for employees who will be working on the project, but also the opportunity cost your paying for having these resources working on the project at hand. Often the opportunity cost of other more attractive ROI projects gets lost in the detailed dollars and cents analysis. This can make for an unpleasant surprise later in the development cycle when the team is beyond the point of return and other more attractive opportunities arise but resources aren't available to capitalize on the opportunity. In the norm a buy vs. build comparison between licensing a technology and building it in house with a true cost comparison for both, will often yield the conclusion that the more flexibility in resources you have the more likely you can afford to buy the technology, rather than having to build it.

The final criterion to consider revolves around your organization's core competencies. This can often be a very difficult thing to address, as many organizations haven't taken the time to identify their core competencies. Nevertheless, you need to make a decision to buy or build and will have to make an educated guess, in the face of uncertainty. If you buy some core technology and then spend your resources customizing that technology to serve your end objectives then the reality is your building a core competency in customizing the technology, not in the technology itself.

This situation changes over time as increasing customization results in a base technology that becomes unrecognizable and resultantly you could fairly make the claim that you have built a competency in the technology in question. However, this evolution can take a substantial amount of time and is not a certainty to arrive. Therefore, when considering the buy vs. build decision with respect to core competencies, the more you want to build a core competency in a technology the less likely you are to buy it. However, the more ancillary the technology your looking to buy is versus core to your competency base the more likely you can buy it.

Hence when making the all important buy vs. build decision for a high tech company consider when you need to make the product available, how much resources you have at your disposal and how close to the core of your competency base the products lies. If these questions can be definitely answered either yes or no, then you'll have your answer very quickly.