Why?  Because it represents a false dichotomy.

“Build” part of that equation implies that you are either starting from scratch, or at the very least, have a very long road ahead, wrought with long requirements sessions, prioritization arguments, and project delays and overruns.  It brings to mind images of 6 hour pizza-catered sessions, Gantt charts, and difficult conversations.  It comes with high support costs and staffing issues.  Ultimately, however, you will get something that meets your exact specifications.

On the other side, “buy” implies that you will get what you need out of the process.  Yes, there will probably be overpromising and underdelivering, and you will likely have to compromise on some things and sacrifice others, but at least you will get the very thing that will help you do your thing at the very end.   You can just pay for maintenance to some entity and they will deal with the headaches.

In what world are these two scenarios true?  Were they ever?

In my almost 25 years of IT, while I saw both “build” and “buy” efforts either phenomenally succeed or spectacularly fail, and eventually corner the company into some box, a way out of which was to do a costly and painful forklift.

Because change.

Taking into consideration the rapid pace of improvement in today’s technologies, and more importantly, the rapid pace of change in our customer’s needs and behavior, it is exceedingly speculative to guess what will be asked of our teams and technologies in a year or two.   And so when we develop our systems to meet our requirements, we are focusing on the needs of today and maybe, just maybe, give 5 minutes of thought to the future.  But historically, the future gets here sooner than we think, lagging ever so slightly behind now.

It’s all about platforms and accelerators.

No “buy” system will ever meet “now” needs fully or account for “future” needs completely.  No “build” project will deliver exactly what’s needed.  What it all comes down to, are two questions:

1. How far towards achieving critical objectives and requirements can I go before I have to customize to meet remaining needs?
2. Can the selected system support both getting up and running quickly, and customizing extensively?

“Buy” would likely get you pretty far towards achieving stated goals and objectives, but will likely limit how much customization you can make.  In fact, it seems that the closer you can get to meeting your immediate needs with a “buy” product, the greater the limiters on what you can eventually turn it into.

“Build” would most likely start out nowhere near stated goals and objectives, but will probably offer great customization opportunities.   It does come with increased support costs.

Picking the right platform and accelerator can give both – quick path towards launch plus ability to hold off the forklift for much longer.

So my argument is that it’s not “build vs. buy” decision, regardless of how snappy and easy saying it is. The whole thing should be framed as “how far towards my goals does this get me and can I drive myself afterwards?”