Should you build or buy software?

Is it better to build software for digital experience and ecommerce or to buy it? Pose that deceptively simple question to Google and you’ll get 1.2 billion responses. That’s a lot to wade through, and no doubt most of the responses are from sources of suspect authority. So instead, we posed the question to actual experts in this month’s private session with The Fleet Club.

It must be acknowledged that there’s a cyclical nature to the build vs buy discussion. We discover (or think) our problems are unique. So we build something to uniquely solve them. Vendors step in and promise “seamless” solutions that address “all” of the issues. Then we discover gaps and repeat the cycle.

There’s also the issue of the blurring of what it means to build vs buy. We’ve lived in the age of Open Source Software for some time now, where it’s rare for any solution to be truly built from scratch. There’s a good chance even your car is now running Linux or another Unix derivative. Add to that the proliferation of SaaS products that can be glued together to solve problems.

In the Martech space alone, there’s now a gazillion different point and “comprehensive” solutions to address a huge variety of needs. So what should you be thinking about when you evaluate build vs buy? Is it even the right question any more?

What should guide your build vs buy decision making?

When we talked with our Fleet Club members, we covered a number of questions that teams should ask themselves when choosing a path. Here are a few questions to consider, some from me, some from our members:

Questions to ask when making a build vs buy technology decision

1. Is the technology core to what we do or peripheral?
2. Is the solution we might build for ourselves key to our differentiation?
3. Do we have the right expertise in-house?
4. Do we have the time to develop it?
5. What happens if when it breaks?
6. Do our needs match patterns or are they truly unique?
7. Can what we need be bought for any price?
8. How do we make it scale?

Let's break those down in a little more detail:

1. Is the technology core to what we do or peripheral?

Way back in 2018 Christopher Mims of The Wall Street Journal said, "Every company is now a tech company." Perhaps taking this to heart, many organizations have emulated tech giants like Facebook and Google, hiring SREs and learning how to manage Kubernetes and similar tech.

Ask yourself critically: does this technology investment make sense? Are we a container management company or a database replication company, or are we really trying to sell clothes, deliver news, or reinvent healthcare?

2. Is the solution we might build for ourselves key to our differentiation?

Similar to question #1, with a twist. Will building this technology or experience in-house set us apart from our competitors or give us a clear lead on the market?

To quote Dr. Ian Malcom from Jurassic Park:

3. Do we have the right expertise in-house?

Implementing new technology can require different knowledge and skills than you may currently have on staff. Do you have the time and budget to hire? Or can you jump-start your initiative with tooling or consulting?

Bringing in outside help in the form of expertise or technology need not lead to a binary build/buy disparity. In fact, augmenting your own internal knowledge, talent, or tech can help your own teams accelerate.

4. Do we have the time to develop it?

Or, to put it another way, what will we not do because we're building a new initiative? Evaluating the tradeoffs and opportunity costs of investments in building IP internally is critical.

In addition to build time, there's ramp time. Is there sufficient time to acquire and ramp up a team to build what you need?

5. What happens if when it breaks?

Often times we focus on getting something done. Shipped. Code-complete.

But beyond the first joyous Hello World, there's the realm of production. In addition to the resources mustered to create the new experience or technology, there's a need to ensure that it’s available when it's needed. Which for most organizations is all of the time. That demands the question: do I have adequate 24/7 or on-call coverage?

Additionally, when we "build" in modern technology parlance, we often mean we're assembling from Open Source primitives. Building on the shoulders of giants by leveraging OSS is a time-to-value boon, but it also requires its own considerations. Specifically, is someone keeping track of all of those components and ensuring that they're up to date?

Even with commercial software, there's risk to be considered when incorporating third-party components, as demonstrated by the 2020 SolarWinds hack.

6. Do our needs match patterns or are they truly unique?

If we go back to Scott Brinker's Martech 5000 8000+ above, it's clear that vendors are filling myriad niches in the marketplace.

First, ask yourself, "Are my needs different enough that there's not a solution out there already?"

Second, ask yourself, "Are there patterns in my own organization?"

This second question leads to what I like to call "fleet thinking," a topic my colleague Patrick Klima and I addressed in a talk not long ago. One takeaway from that talk is that when you're evaluating options for technology deployment at scale in an organization, there's more to consider than the technology alone. It's important to map out the organizational structure and constraints, as well as to understand the diversity (or similarity) of needs across the organization.

Once you've mapped your organization, you can determine the right level of abstraction or flexibility that you need in a solution to enable you to operate as a "fleet" rather than as a collection of individual instances. For example, can you standardize on a single CMS across the organization? Or do you need a platform that can operate at a slightly lower level of abstraction and give flexibility to more diverse needs?

7. Can what we need be bought for any price?

Or to put the question another way, is the assemblage of components truly fit for purpose?

We've probably all been there, when a tool, vendor, product, or project promises most of what we need--except for that one thing. Often that last special piece makes all the difference--or potentially represents the biggest impediment to success. Taking the Pareto principle to an extreme, there may be cases where achieving the last percentage of "done" or of "fit" may actually generate more work than everything else. In this case a bespoke approach may in fact be faster/better/cheaper than an "off the rack" solution.

Perspective from our members

The Fleet Club members had additional specific feedback. Gil Yehuda, Head of Open Source Engineering and Technology at US Bank, even authored an article on the subject. Gil's thesis gets right to the heart of the matter:

In his post, Gil also points out a frequent dichotomy between engineers and non-engineers, and their preference for building vs buying, and also the need to address dreaded "vendor lock-in."

Another Fleet Club member added to Gil's perspective. They suggest that organizations should look at Open Source as a model to jump-start innovation. While we often think of OSS as a means to acquire "free" software without license costs (the "free-as-in-beer" argument), it's the "free-as-in-freedom" value of OSS that can allow organizations to take software and extend it to suit particular purposes that are unique to their organization. I wrote a bit in a past post about benefits of Open Source for organizations.

We also heard that characterizing relationships as vendor/client can be unhealthy. Instead, one Fleet Club member suggests that we instead reframe these relationships as partnerships to augment capability and align interests. This may seem like a minor word choice, but it puts the players on a journey towards a goal together rather than on opposite sides of a transaction.

Finally, we heard about the importance of understanding your internal constraints. As in our points above about internal talent, timing, budget, and even politics, it must be understood that simply understanding technology is insufficient in solving technical problems. Understanding and addressing interpersonal and interdepartmental dynamics will determine both the best path and likelihood of success.

Why the question was wrong, and what to do about it

Our Fleet Club session brought together digital leaders from organizations that spanned media, software, financial services, education, and more.

The clear takeaway: there's no single answer to the question "do I build or buy this" and, in fact, the true answer is derived from a combination of organizational, timing, and strategic factors.

When you're making decisions on technology directions or selecting partners to join you on your journey, it's critical to ask key questions like those The Fleet Club outlined above and to determine the proper level of abstraction you need to accomplish your short- and long-term goals.

If you want to join our upcoming conversations, you can find out more at Fleet Club.