The reality of buy vs. Build. It is a question I often dive into, around and through with customers and internal teams. Buying something that exists reduces the cost of R&D for an organization. It reduces the cost of version 2, 3 and so on. It, however, can have an initial upfront layout that can be risky. Or worse than risky can frankly be expensive. Managing cost containment vs. capabilities is an interesting modern IT problem. Buy vs. Build is less done today that it was 20, 25 years ago. In fact, I would say the vast majority of organizations I worked with in the past that built solutions most likely have abandoned those solutions moving to purchased solutions.
When you factor in training, and you factor in upgrades you begin to separate the reality of buy vs. Build. First off, if you are making something in a software solution that doesn’t exist anywhere else, it is important to note that the discussion we are having about buy vs. build isn’t possible. When it is something that isn’t in the market today, you are building it. There are things that do require new. New is the enemy of buy. Yes, many companies build new solutions that have wonderful new features, but the reality is, those features are less likely to explode a brand new market. New markets are risky for software solutions because they are new.
If you crack the new market, you can be a member of the blue ocean club. Blue oceans don’t have blood in the water (where blood isn’t sharks feeding, rather it is competition). Every company and every startup entree en dreams of the reality of the Blue Ocean. (the Blue Ocean Theory comes from a book by the same name. It is an amazing book to read). Being first to market can truly be amazing. But if the market already exists, then buy. Make sure you don’t bet tomorrow on a market that doesn’t exist today in every part of your life. Sometimes it is ok to be with the odds. Gamblers that make a living at gambling don’t be the long odds every time. People that are lucky the long odds and win.
Buy, vs. build!