Technology Build vs. Buy – A modern perspective

My first job after college was with a mainframe computer software provider.  Admittedly, I knew very little about the software industry when I started.   I recall asking the interviewer, “why do companies buy your software when they could build it themselves?”  I would often ask myself, my colleagues, and my organizations that same question over the next 35 years.  

Today, this question has become even more difficult for organizations to answer with the advent of low/no code tools, improved software development techniques, automated testing, standardized protocols, and accessible application program interfaces (API).  

Recently I was on calls with numerous companies discussing the merits of various tools for use inside their respective technology organization.  I listened as they debated among themselves and the vendors on the value of the applications.  Those discussions brought me back to that same old build versus buy dilemma.   

Those calls served as an inspiration for me to write this article.  Anyone who has ever worked with me can attest, I have strong convictions on this subject.  But before I jump in and talk about how one should go about making that decision, let’s qualify the decision criteria.  

The question to build versus buy assumes a few things.  First, is there a viable off-the-shelf solution (packaged software or SaaS) that exists from a reputable company?  Second, do we have development resources available to build and support the solution needed?

As the above matrix shows, the decision I am discussing comes into play only when both questions can be answered “Yes.”  As you might imagine, there is more to the third scenario (“no” and “no”), but we can save that for another blog.  

With all of that as background, how does an organization make the build versus buy decision?  I believe there are five key criteria for making this decision.

1. Solution Purpose
2. Internal Organization's culture & track record
3. Package/SaaS Fit
4. Time to value
5. Total cost of ownership

Solution Purpose

Years ago, at Lowe’s, we performed an application portfolio analysis.   All the applications in the company were slotted in one of nine quadrants, as shown below.   The vertical axis was the application type.  “Standard” applications are ones that any company would have (General Ledger, Human Resources, etc.).  “Industry” applications are those that companies in a specific industry would have (point-of-sale for retailers, for example).  Finally, we identified applications that afforded a unique consumer experience as “Differentiated.”

The horizontal axis indicated where we believed the capability of the application was relative to industry peers.  As each application was slotted, it was color-coded as green (core solution), yellow (emerging solution), or red (declining solution).

This exercise exposed troubling behavior.  We placed an excessive amount of resources and cost in “standard” applications while not providing enough emphasis on those applications that differentiated our customer experience.  

I bring up this example as it still occurs on a routine basis.  Organizations allocate too many resources and cost for applications that do little or nothing to differentiate.  I see this happen way too often when technical organizations want to build utilities such as orchestration, APIs, and automation (such as RPA) when proven and affordable solutions exist on the market.  

You can apply this lesson to a build versus buy decision.  Applications that don’t differentiate the core business should be bought.  Differentiated applications are not ones you usually find “on the shelf” and should be built.

Internal Organization/Culture

Understand, IT folks are among the most optimistic in the world when it comes to what they believe they can do.  Most of the IT people I know (I include myself in this category) want to innovate, create, and “wow” the customer.  But wanting to do and having the capabilities to do so are two different things.  

Sometimes, the hardest thing for IT organizations to do is to look in the mirror.   If the IT culture does not foster innovation, speed, agility, and delivery, then “buy” should be the first option in the build versus buy decision.  If IT has a proven track record, then all options should be on the table.  

Package Fit

There is an adage, “you can’t fit a square peg into a round hole.”   In that same vein, trying to make an application do something it is not designed to do is an exercise in futility.  In my career, I can recall a few occasions where we tried to make an application “fit” either from a functionality standpoint or from a technical architecture standpoint.  In all cases, the results were not good.  To measure package “fit,” you must have a good grasp of your requirements.  In cases where requirements are not well understood or are evolving, building (at least to a minimally viable product level) is often the best bet.  

When we say “good fit,” we include functionality and architecture.  Understandably, architecture has become less of an issue thanks to the Cloud but can still be an issue for certain applications.  From a functionality standpoint, the solution must be able to perform the core requirements without requiring modification.  Resist the urge to customize purchased applications.  A customized purchased application is often the worst of both worlds – inflexible and costly.  

Finally, you should consider ancillary requirements as such.  In other words, don’t let exceptions become the rule.  Focus on the critical few.   If the package fits your technical and functional requirements and your budget, you should buy it.  

Time to Value

Most people assume packaged applications offer faster speed to value.  This assumption is true, but only if you have performed the appropriate due diligence.  Due diligence means evaluating fit (see above), having resources with appropriate skills to integrate the application, and involved business resources to guide the configuration processes.   As discussed previously, if the package fits the business and technology needs and the software provider has a good track record, buying will almost always be faster than building.   

An exception occurs when the “critical few” requirements are much smaller than the packaged application’s footprint.  If the “critical few” are a small enough subset, then building to a minimally viable product may be quicker, at least in the short term.  

Total cost of ownership and return on investment

Cost is often a driver in build versus buy decisions.  But the initial cost to build/buy is only a small part of the equation.  Once deployed, application costs include maintenance, enhancements/modifications, and operating environment refreshes (such as operating system upgrades, security patching, browser upgrades, etc.).   Packaged solutions include these costs in the annual maintenance or subscription.  SaaS solutions include these costs in the subscription.  The labor needed to provide these capabilities in custom-developed solutions is a variable cost.  

I love SaaS models because organizations can no longer “kick the can down the road” when deciding whether to accept an upgrade.  When a new version of an application is ready, the provider will provide notice, allow for some testing, and then upgrade.  I have witnessed application updates delayed for years due to costs, resources, “disruption”, and other reasons.  The mandate that keeps organizations current on updates is truly a hidden value of SaaS ownership.  

Another value of buying a solution is that enhancements are often included.  To ensure we received the most from a software investment, I always encouraged our teams to be heavily involved with the software provider’s steering committees.  Since software providers receive enhancement requests from a multitude of customers, the resulting upgrades can be considered quasi-proxy for industry best/preferred practices.  

An obvious advantage of building an application is that it affords you complete control over the enhancement cycle.  As such, the enhancements most important to you will always be prioritized first.  However, you must be aware of your development and testing costs associated with each change.  Another cost is opportunity cost.  If you have developers maintaining non-mission critical applications, it is time that could have been applied to more business-critical items.  

The key takeaway is to factor in all the costs associated with owning an application and make an honest assessment on the level of changes you anticipate.  

Summary

We live in a low-code, no-code world for development.  Software developers are more productive now than ever before.   Pre-built APIs, automated testing, and other advances allow organizations to build applications faster and with higher quality than ever before.   These tools make it tempting to try to tackle software tasks that would previously not have been considered.   However, doing this without assessing the alternatives can result in longer delivery times and inflated costs.  

With that in mind, I believe it is still crucial for organizations to review and understand the alternatives based on the five criteria we reviewed.   There are no substitutes for performing due diligence and assessing the pros and cons of buying versus building.  

Finally, I created the simple decision tree below based on an organization faced with the decision to buy an available application (or SaaS) or use available resources to build.   I made a couple of assumptions in this decision tree.  First, you can’t purchase “differentiated” applications.  Second, you can’t build a cost-effective, non-differentiated application on a fixed timeline.