Build vs. Buy: Technical Debt and Unique Differentiators

Think as we might, we cannot think of a single facet of business that has gone untouched by shifts in technology.

The big question businesses should always be asking themselves is the level of involvement required to evolve on pace with the technological vanguard.

Commodity Versus Differentiator

From our perspective as a technology company, we do whatever we can to ensure that our engineers aren’t reinventing the wheel or the ESP or anything else that would fail to differentiate us as a company.

The build-vs.-buy argument comes down to what “build” represents as opposed to “buy.”

If you lack an established and commoditized capability, it is likely a better bet to buy than build. It’s easier and more efficient to lean on a partner and reap immediate ROI than to tie up engineering hours trying to repeat the success of someone for whom the capability is a core differentiator.

One example from Simon Data would be our need for scalable compute resources. Rather than build server warehouses, we rely on Amazon’s AWS, which also lets us flexibly increase compute power during use surges, like around the holidays.

If a capability is a core driver of value and a strategic differentiator, it is likely something you want to build.

No matter how stodgy and traditional, businesses must accept that content and technology are inextricable from core business in every industry and vertical.

The technology that you pour resources into must create a unique value for your customers. If there’s no laser-focused use case behind the necessity of building an ESP or CRM in-house, then you likely don’t need to build it at all.

On the other hand, if you’re in the fortunate position to have a clear aim toward delivering value through a technology that’s unique to you, then shedding the dead weight of inessential workloads building erstwhile-commoditized capabilities will help you get there faster.

An apparel company may be hard at work building a portal that would bring the digital experience closer to an IRL experience — which, these days, some might consider to be God’s Work. This retailer has its engineering team pushing the bounds of creativity and current technology. They don’t need to disrupt realizing their vision by establishing a team to build run-of-the-mill (or even slightly better) heat-mapping software to inform UX and Marketing of conversion-rate optimization opportunities. While the capability is a necessary component of growing the business, the question of who built it is less important (if it’s important at all).

In other words, “build-vs.-buy” is only settled through evaluating all of your planned or “someday/maybe” builds against a possible purchase or partnership opportunity.

It may be encouraging to know that this step isn’t easy even for us, an engineering-first technology company.

Technical Debt Versus Flexibility

The other critical factors in the decision to build or buy are maintenance, ongoing improvements, and added complexity, all of which can roll into the idea of technical debt.

The truth is that naming the decision we’re discussing “build vs. buy” makes this decision sound comparable to “Cook vs. Order In,” which betrays the level of commitment required from the former half of the equation. In reality, it’s more like “Start a Farm vs. Go Grocery Shopping.”

Unless you only need a new capability for a limited time, there’s no such thing as a one-time build. For every new capability, you will need to dedicate future resources to maintenance and upgrades in perpetuity. Even letting a technology go to seed before migrating can often cause more headaches than it solves.

One must also consider the sophistication required of a given solution. If you need a solution that helps you compete but won’t become a core differentiator, shopping for a best-in-class solution will be more efficient than shopping for a whole engineering team to assemble that solution.

We’ve seen among our clients that the build-mindset runs the risk of walling out non-technical marketers and experience leaders. Unlike out-of-the-box solutions, not much sweat is spent on in-house solutions’ accessible UI or UX. This creates friction in execution and end channels, cumbersome workflows, and interdepartmental bottlenecks — all of which only serve to slow down operations.

As came up in a recent Executive Roundtable, your technology is only as future-proof as it is easily jettisoned. In other words, bias toward speed over robustness. As one Executive Roundtable guest put it:

“The best strategy is to accept that things are going to change. Rather than future-proof, prepare for the future by minimizing the risk of pain and keeping your organization open to opportunities that the future holds.”

This might be one of the best arguments for outsourcing: flexibility is the only true path to adaptability, and the companies that adapt most quickly are the companies that succeed. The companies that don’t adapt…ahem…Blockbuster Video comes to mind as an example that won’t offend anyone. 

To recap, the question of build vs. buy points to two variables:

• Is this capability a unique core differentiator, or is it a commodity?
• Will the adoption or creation of this capability accumulate a technical debt or empower technological agility?

For more on this and other considerations around using the right technology for your company and unique use cases, check out “Turn Your Tech Stack into an Ecosystem: A Technologist’s Guide” by Simon CEO Jason Davis.