Build Versus Buy

Consciously or unconsciously, as software engineers, we perennially take build versus buy decisions. It might be as trivial as copy-pasting code from somewhere versus racking up our brains to write our own; using an already available library or creating one from scratch; using a time tested framework against designing one; building a piece of software internally as compared to buying one.

The way we account for the build versus buy decision varies. Some of the frivolous reasons for building in-house are NIH syndrome, hubris, and planning fallacy. We generally tend to overemphasize our expertise, knowledge, and capability which naturally lead to building internally. Also, we underestimate the amount of work involved in creating software, only once we get our feet wet does the reality set in. A very valid reason for building internally is the cost, but when accounting for cost, we usually overlook the hidden cost of developing software. Buying a software has an upfront monetary cost whereas by building internally we pay in the form of opportunity cost, talent cost, feature cost, etc.

Build versus buy arguments are reminiscent of qualitative speak – “This is not our core expertise, we should be concentrating on solving our business problems”; “This is going to cost us a bomb, let us build in-house”; “We should have had this yesterday, building in-house will cost us another 6 months”; “Will that external product be able to handle our scale”; “Can we trust them with our data”; etc. In most cases, build versus buy decisions are qualitative, it is not an easy exercise to quantify them.

When evaluating a product that is already out in the market versus building something similar, a cardinal mistake people commit is mapping features one to one. Even though having 100 different features looks rosy and attractive, usually we end up using only a select few. Instead of trying to match an external product feature to feature, scope out the features that you need or would probably use and then estimate the effort. Another is refinement. An external product will be refined and polished, but you may not need the same level of sophistication. For example, you might not need a web interface for the product; a terminal would work fine for your use case.

When faced with the build versus buy decision, asking the following help:

• Is this my core expertise or is it something I can let others do for me?
• What is the cost of getting this done externally versus hiring people to build this?
• How much control do I need over this, i.e. can I live with some error, downtime or opaqueness?
• Will I do a better job building this internally?
• Do I have the expertise needed to build this?
• Once I build this, will I be able to maintain and enhance?
• What is the opportunity cost of having this sometime in the future versus having it now?

Use the answers to the above as a beacon for the build versus buy decision.