To Buy, or Not To Buy. To Build? is the Question

builder fresco

Should we buy this application, or build it in house? Maybe some of each. How should we make that decision today?

Build, Buy, or Both?

This is somewhat of an age-old debate. IT departments were initially chartered with cost-reduction initiatives. Automate this process, reduce errors in that process. For some companies, IT departments stopped becoming a cost-center and started becoming a profit-center. Initiatives began to appear that were designed to enable top-line growth, not just cost-reductions. Enable this sale, encourage that one.

As companies objectives for the use of software evolve, we should probably revisit the age old question of build versus buy. But there’s also a middle ground – do some of both. Almost all enterprise software is intended to be customized. Many open-source products are created as extensible frameworks. Companies package applications into suites, and distribute stacks (collections of open-source software, pre-assembled and validated to work with each other).

The game hasn’t changed, but the players have. We should revisit this question.

Their Answers

This question has been asked and answered before. Collecting the answers that have been out there for a while:

  • Packaged product vendors tell us to buy. “You should focus on your area of expertise, your products, and leverage our area of expertise, our products.” A very compelling argument. For any given IT department, any particular project is a one-off project. The IT department of an air-conditioning unit assembler/manufacturer is going to have little or no experience in developing a CMS (content management system). A community college is unlikely to have billing and invoicing system experts in-house. The argument is that it will be too expensive for these inexperienced teams to work through the hidden complexities and difficult problems of developing these systems. A vendor of one of those systems will be staffed with experts in that particular system. The packaged software vendor will have been distributing the cost of solving those problems across multiple customers. No one can build Quickbooks for $300. A company is better off buying this packaged software and tweaking their accounting system to use it.
  • Many IT workers tell us to build. Any of a number of factors cause people to present this argument. We should dismiss the specious arguments that all fall in the “not invented here” category, or are self-serving. I once worked with a client who’s motto was “Invent.” Their IT team took that to heart, and perhaps selected to build when they should have bought. I also worked with a client who’s motto was “Think.” I believe their IT department did a better job in thinking about when and when not to invent. There are certainly situations when building is appropriate. There may not be a product available for purchase. There may be intellectual property considerations – if Dell is looking to further reduce their lead times or increase their inventory turns, they may want to do that work in-house, simply to prevent outsiders from learning what they already know. In these cases, the IT department does have expertise to rival or surpass the software vendor.
  • Enterprise Software is some of each. Enterprise software vendors apply a modified version of the packaged software vendor’s argument. They will point out that the hidden problems are so complex, or the scope of the solution is so large, that no independent IT team should even attempt to solve it. And they generally have a point. But this argument can be weakened. Thirty years ago, no one would consider running a business on Quickbooks. Accounting practices are different for every company. Intuit decided that there was an underlying theme of commonality, and built a company around that theme. Their customers compared the costs of adapting their accounting to match the software with the costs of custom-developing a solution (or paying an enterprise software vendors to customize their “starting points”) and decided that process change was cheaper than product purchase. Enterprise vendors still have an advantage when there are no alternatives that are “close enough” to their solutions.
  • Open Source is All of the Above. Open source solutions are “free*.” Companies can download and install free software that attempts to be equivalent to packaged software – install and use. Subversion is a great example of this – a company can install subversion as a source code control system, or they can purchase a solution like MKS, Clearview, or Visual Source Safe. Open Office competes with Microsoft Office. AVG Anti-virus competes with McAffee. Open source solutions may be development environments like Ruby on Rails. They are designed to reduce the cost of building a solution. The more interesting open source solutions are frameworks and stacks. Drupal is as much a framework as it is a CMS. A company can build a solution by enhancing a “free” framework with a combination of free modules and custom-developed modules. A company can build this solution to run on a free operating system, a free webserver, and a free database. A vendor may sell a “stack” of free packages – certified by the vendor to work together. Some stacks are even free – like LAMP (linux + apache + mySQL + php). Combine a LAMP stack with Drupal, and you may have 90% of the functionality of an enterprise software solution. A small amount of (additional) customization can get you to the same end result with a much smaller price tag.

*Free, in this context means that other costs are relatively equivalent to other choices – training to use a new process, or new software, or both, is roughly the same for all of the choices.

Hat tip to Francis Dion, for his recent article on this subject. Here’s his opener:

Back when I was a corporate IT staffer, I used to hate arguments such as this one, confident in the belief (like everybody else in this business) that we could do better than anything that existed out there.

Now that I am a bit (ergh, quite a bit :-) more seasoned, my views on this topic have changed radically.

Buy vs Build

Finding Your Answer

Ultimately, each decision will have to be pragmatic, and will depend on a number of constraints and factors that are specific to your business. Assuming you have already ruled out the infeasible products and approaches that you deem to be “too risky”, you are left with a set of solutions. Now filter those based on your constraints:

  • Financial Constraints – are you bootstrapping a startup, or trying to burn through some VC cash?
  • Time Constraints – do you have a year to get something built, or will you be sacrificed in a month if your solution isn’t live?
  • People Constraints – do you have people with the skills to build or extend and support custom development. If you answered yes – ask yourself again – do you really?
  • Intellectual Property – will this software be leveraging or enhancing your core-competencies? Is your business model dependent upon differentiation in this space? How much would it hurt if your competitors (inexplicably) started doing the same thing?
  • Vision – your company may have a strategic vision for developing tools to support it’s ongoing business. Not sure why, but maybe you do. Don’t change your nature because of math. Stick to it, and good luck with that.

Select By Value

Once the constraints have narrowed the range of possibilities, we have to make rational decisions based on ROI.

We start by understanding our requirements – why are we building or buying in the first place? We then narrow our possibile choices to those that would achieve our goals.

We look at the TCO (total cost of ownership) of each solution approach. This includes purchase price and maintenance fees (if any), development costs (in-house or outsourced), and training / process re-engineering costs (if any).

We combine the expected gains and costs to identify the expected value for each approach.

We look at the timeline for how quickly we can get a solution in place, and incorporate that timing into our ROI analysis – leveling the playing field by comparing the net present value (NPV) of each alternative.


There isn’t a one-size-fits-all answer. Generally speaking, look at your options, apply the constraints of your reality, then do the math.

8 thoughts on “To Buy, or Not To Buy. To Build? is the Question

  1. best TCO sometimes comes from a combination of approaches; there are many times when buying part of a solution and building ontop of it is the best choice.

    IT as a whole, whether open source or enterprise, seems to move in this direction. now you see build vs. buy not just on internal IT projects, but customer facing products. examples are situations where one wants to build an online application that can scale: now companies have platform choices a companies like Apprenda, 3-tera, and ActiveGrid seem to provide solutions for this under different guises (grid operating system, saas platform, on-demand platform, etc.)

  2. Good additions, Carlin, and thanks for reading and commenting!

    I really like the modular software approach for IT projects – the granularity of build vs buy is smaller, allowing for more optimal approaches. People can do a mix, exactly as you describe. It also allows overworked teams to easily subcontract “build a module” type jobs to third parties.

  3. Thanks James, good general advice – I think that works as a rule of thumb – generally, that’s how it would play out for the companies I’ve worked with, when a purchased solution option is available.

  4. at times great additions come up in the building phase, mainly in the form of some brilliant brains within an organization. The open system will work in an effortless manner with simple clean coding. The sad part is that the open source community rarely gets back such gems.

    don’t you think it would be nice if the open source is really open, even in the context a corporate house built it?

  5. Hey Sam, thanks for reading and commenting!

    I haven’t had the experience of extending any of the open-source products yet, although I expect to in 2007. There do seem to be a lot of extensions that make it back into the products, but as you imply, it may only be the tip of the iceberg.

    Other folks – if you’ve worked with a team that extended an open source product – did your team push those extensions back into the community, or keep them? And why?

  6. Scott, I was thinking of a few reasons like:

    – Difficulty in maintaining home-built code.
    – Writing quality, bug-free code in the desired timeframe and to ingrate it as well!
    – Is this a common code to be used across product lines, or is it meant for just one product?

    But all these reasons can be categorized into your top 3 reasons: financial, time and people constraints. In addition, this post and comments cross-reference some useful pointers as well.

    Merry christmas and a very happy new year!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.