The build vs buy decision starts with purpose

If you’ve ever customized a purchased system, or found that a system you built lacked many expected features, you made a build vs. buy choice.

And the odds are you chose poorly.

Maybe you’ve already made that mistake. If you haven’t yet, the moment is coming. The spreadsheet or shared doc holding a process together stops being enough, and you have to decide what comes next.

With ‌AI, the answer can feel obvious. You’d build it, and you’d use AI to help.

Not so fast, my friend.

The purpose of the business process you’re supporting should weigh more heavily on that decision than the technical questions do, and you should work through it before you get anywhere near those questions.

To show you why, I want to walk through my experience as product owner for Agile Alliance, a nonprofit that supports people who want to adopt agile methods. It’s the best example I’ve lived through of what the product owner role should look like, and it includes both a decision I got right and one I got wrong.

I was part of the team that rebuilt Agile Alliance’s website a few years back, which included its membership system and event registration system. The agency we worked with built both from scratch on top of the new site.

I was also responsible for the conference submission system, the tool behind the Agile Alliance’s annual conference for agile practitioners. What made that conference different was its session selection process. A group of volunteers reviewed every submission and gave feedback so that submitters could revise their proposals before a final decision. Most conferences just tell you yes or no, with nothing in between.

We built that system specifically to support that unusual process. It wasn’t perfect, but it did a good job supporting the part of the process that actually made the conference different.

Build or buy is not a technology decision

When organizations face a build vs. buy decision, they usually weigh cost, speed, what’s available in the market, and how feasible it is to build the thing themselves.

Those are all valid criteria to look at. But without a longer view, they can mislead you.

Building something can look cheaper than paying a monthly subscription until you count the real cost of building and maintaining it.

Buying an existing product can look faster than building your own, unless you fall into the classic trap of thinking you could build a better CRM than that over a weekend.

Then there’s the question of requirements: what you think you need the system to do. The more particular you are, and the more attached you are to your current process, the harder it becomes to find an existing system that checks every box.

AI changes the math here too. It makes the build choice look more attractive because it makes building easier. Unfortunately, it makes building easier for your competitors too, so anything you build to stand out becomes easier for them to copy or beat.

My experience before and after AI is the same. A build vs buy decision that looks obvious can go badly wrong when it conflicts with the purpose of the business process behind it.

Poor decisions in both directions

When I was product owner at Agile Alliance, I had responsibility for the organization’s key systems, both custom-built and purchased.

That also meant I had plenty of chances to get the model wrong, or to get it right and watch the decision get reversed after I moved on.

Treating parity activities as if they were differentiating

When we were getting ready to rebuild the Agile Alliance website in 2016, we pulled together requirements and sent them to a few digital agencies for proposals covering the website, conference registration, and membership systems.

We bundled all three together because both the paywalled content and the conference discount depended on knowing someone’s membership status, and that single requirement led the agency to propose building registration and membership from scratch on top of WordPress.

Membership and registration both matter. But Agile Alliance never stood out from other professional associations based on how people registered for a conference or signed up for membership.

Those were parity activities.

The agency read the membership tie-in requirement as a reason to custom-build the whole thing inside WordPress. They delivered the tie-in, but left out a lot of the basic functionality you’d expect any conference registration system to have.

We treated parity activities as if they were differentiating, and ended up with parity gaps: we couldn’t manage memberships or register people for a conference as efficiently as other professional organizations could.

After about six months of limping along with a barely functional membership and registration setup, we fixed both problems by buying a membership plugin for WordPress and subscribing to a cloud-based registration system.

What changed our minds? We realized we didn’t need our registration system explicitly wired into membership roles. It was enough to control which registration path a member saw versus a non-member. We focused on the result the requirement was pointing at, instead of the literal requirement itself.

The lesson: put the right amount of weight on requirements and don’t let them convince you that something is differentiating when it isn’t.

Buying what it should have built

I was involved in the original decision to build the conference submission system, and ‌that decision was clear-cut. We were preparing for the Agile 2013 conference, and the system we’d been using was outdated and built on frameworks that no one supported anymore.

We knew our selection process differed from every other conference’s, and we considered it central to the whole conference experience. Building a new system was the obvious choice.

Having built it ourselves meant we could keep improving it from one conference to the next, often alongside changes to the selection process itself. Those regular changes to kept the experience good for submitters, reviewers, and attendees.

My last conference cycle with that system was heading into 2019, before I moved on to a new opportunity. At that point, it was still running and still supporting a selection process nobody else had.

Then 2020 happened, and in-person conferences stopped.

By the time Agile Alliance restarted them a couple of years later, the team that supported the submission system was gone, and new leadership was in place. They decided to replace the custom system, but instead of building a new one, they bought an off the shelf submission tool.

That tool debuted for Agile 2024, and I was on the conference team that year. It quickly became obvious that the new tool didn’t support the process that made Agile Alliance’s conference different. The team tried manual workarounds, but most of them didn’t produce the same result as the process they replaced.

My advice at the time was to either build something that supported the real process, or accept a more common process the tool already supported. The leadership chose the second option.

A differentiating process was made parity.

Start with the purpose of the business process

If you’ve read Not every system request deserves innovation, you already know how to approach a system change based on the purpose of the process it supports. The same idea applies when you’re choosing an entire system.

Is the process differentiating? Build it.

Is it a Parity process? Buy it.

Before you apply that heuristic, make sure you judge the entire process, not just a segment. If I’d done that from the start with membership and registration, I’d have been a lot more suspicious about building a custom solution for two activities that were obviously parity.

Differentiating activities call for building

Differentiating activities are the ones that set you apart in your market and help you win business. Because of that, you need to be good at them, and different from your competitors at them.

That means any system supporting a differentiating activity needs room for innovation and creativity your competitors don’t have. You can’t get that from a system you purchase. You build a system to match your process.

It’s not just a good idea to build a system to support a differentiating activity; it’s essential because you’ll need to keep revising that system to stay ahead. Otherwise, your competitors can go to school on your differentiator and drag it down to parity.

Parity activities call for buying

If an activity is parity, you gain nothing from doing it uniquely, and it can actually cost you to try. Keeping up with competitors on a parity activity usually means replicating characteristics you’re not even fully aware of.

The easiest way to do that is to buy a solution built by people whose entire business is capturing the good practices everyone in that space already uses. That’s what SaaS products do well.

When you buy one of those, you adjust your process to match the system, not the reverse. The good practices are already built in. There’s no advantage to being unique here.

What about buying software and then customizing it?

If you buy a system and then think you need to customize it, that’s usually a sign of one of three things:

1. You bought the wrong system.

2. You didn’t adjust your process enough to fit the system you bought.

3. Or, rarely, you’re actually dealing with a differentiating activity for which you should have built a system from the start.

That third option is uncommon. Since organizations rarely have more than one or two differentiating activities, the need to customize a purchased system is a sign you’re trying to treat a parity activity as differentiating.

Use the build or buy filter

The next time you’re facing a new system, or replacing an old one, work through these questions before you compare tools:

• What complete activity will this system support?

• What outcome does that activity need to produce?

• Is that activity differentiating or parity?

• Does your instinct to build or buy actually match that answer?

Reply and tell me: what system decision are you stuck on right now, and does it feel like something that makes your business different, or something every business like yours handles the same way?