Build vs. Buy: I Thought We Had Settled This Already...

Archive | Upgrade to Premium | Sponsor

Hi {{FIRST_NAME|readers}},

"We can build our procurement tools ourselves for half the cost."

I've started hearing this again in the "Age of AI"…

The math looks compelling on paper:

No brainer… We should "Build" instead of "Buy"!

Right? Right…? 🧐

Here's what that math misses.

Building isn't a one-time cost. It's a forever commitment.

That "four month build" becomes a permanent job for your IT team. Software decays. Requirements change. APIs break. Security vulnerabilities emerge. That developer who built it leaves, and suddenly nobody knows how it works.

(Just like that freaking Excel file…)

Meanwhile, your vendor spreads these costs across hundreds of customers. They're tracking every LLM update. They're handling compliance before you know regulations changed. They're solving edge cases you haven't encountered yet.

And here's the kicker: AI makes this worse, not better.

"But we can just use AI to build it faster by generating the code!" Sure. And then what? You're still maintaining it. You're still updating it when GPT-5 drops. You're still on the hook when procurement regulations change. You're still debugging it at 2 AM when something breaks before a board meeting.

The teams getting this right understand one thing: your competitive advantage isn't software development. It's procurement excellence.

Build custom workflows? Absolutely.

Build the platform itself? That's like growing your own coffee beans because coffee seems expensive…

Today, I'm breaking down exactly when building makes sense, when it actually might work, and how to evaluate “platform vendors” without getting fleeced.

The real question isn't "can we build this?"

It's "should we distract our best people from what actually matters?"

Onwards!

P.S. The Pure Procurement Newsletter is partnering on content with Pivot going forward. Check out the announcement here.

📰 In this week’s edition:

Note: Some of the content listed above is only available in the email version of this newsletter. Don’t miss out! Sign up for free to get the next edition.

👀 In Case You Missed It…
My Best Linkedin post this week:

What’s the one role procurement can’t survive without? Hint: It’s not who you think.

With AI dominating every conversation from the boardroom to the water cooler, there's been a resurgence of something I thought we'd buried for good: the Build vs. Buy debate for procurement technology…

I find it puzzling.

Even with AI in the picture, the fundamental considerations behind this discussion haven't changed one bit!

Build vs. Buy is, and has always been, a conversation about strategy, core business, and focus.

For most businesses, their “core business” is related to their industry: banking, manufacturing, professional services, retail, etc. It's the primary activities that allow you to create value for customers, derive revenue and develop margin through a competitive advantage.

Most businesses have trouble just doing their core business well at scale:

Last time Bain checked, 88% of digital transformations fail. And that's just for adopting technology… Not building it from scratch.

Most businesses are constantly wrestling with the challenge of simply allocating resources efficiently to their core business.

Why in the world would you add software development to that list?

If you're going to build software in-house (AI-powered or otherwise), it means you're planning to add software development to your core business.

It means you plan on dedicating a non-negligible amount of resources to the development and maintenance of software indefinitely.

Because here's what nobody tells you: developing software, especially if it will support important business processes, creates "lock-in" of your precious resources.

To illustrate, building in-house means:

If you’re doing the above, you're not using that precious time and resources to do something else… Like, say, your actual core business. 😅

Properly developing and maintaining software is a skill. It is such a skill, in fact, that whole companies make it their only, core business.

And most of them fail… 😅 90% of startups fail, with 10% failing within the first year. In the tech sector specifically, that number holds steady even for companies whose only job is to build software!

These are companies with:

Their core business is developing software… And they still fail at alarming rates.

So when your IT director suggests building a custom procurement platform with some Chat GPT wrappers, you should be skeptical. Very skeptical.

"But it's different now," your CIO insists. "With AI, we can build things faster. We can use AI to write the code!"

Sure. And AI can also write your blog posts, but you still need to know what makes a good blog post, don't you?

AI doesn't change these fundamental truths:

I get it. The attractiveness of developing your own software boils down to control.

You get to develop your software in any direction you choose, according to your priorities, without needing to lobby a vendor and jostle against other customer priorities.

That sounds appealing. It really does.

But that control is an illusion.

Here's what does make sense: a “fit-for-purpose” platform with robust configuration capabilities and good business/functional analysts.

Modern procurement platforms offer:

A good, true platform gives you the control you want while removing the burden of software development you don't need (or want… Trust me!)

It’s the best of both worlds.

I'm not saying "never build." I'm saying the bar should be extraordinarily high.

Building in-house might make sense for:

And even then… With a good platform, you can build what you need on the platform! Chances are you’re using Microsoft Power BI for #6… And that with a good procurement platform, you could build #1-6!

Notice what's not on that list? Your core procurement platform. Your supplier management system. Your contract repository. Your spend analytics engine.

When your IT team comes to you excited about building custom procurement software, ask them these questions:

Building software instead of buying it is like building a cabin in the woods one weekend and then never maintaining it.

Sure, it's impressive at first. Your friends come by, they marvel at what you built with your own hands by sacrificing your whole summer.

But then the roof starts leaking. The foundation shifts. Termites find the wooden beams. The paint peels. The plumbing freezes.

And now you're spending every weekend driving out to that cabin, trying to patch problems, when you could have just rented a professionally maintained property and spent that time on other things that matter more.

Everything is in a constant state of decay.

Just because you can develop something doesn't mean you should.

Business is the art of building (and constantly rebuilding) a card castle:

You have limited time, limited resources, and unlimited problems to solve.

So ask yourself: Is developing and maintaining procurement software really where you want to spend your most valuable commodity… Your time and attention?

For procurement teams, IT is a support function. Just like procurement itself is a support function for the broader business.

Neither should be your core business unless you're in the business of selling IT services or procurement consulting.

The equivalent of "Build vs. Buy" for procurement would be asking: Should we grow our own coffee beans, roast them, and brew our own coffee for the office, or should we just buy coffee from a vendor?

You'd think that's ridiculous. And you'd be right.

The same logic applies to your procurement technology.

Your procurement platform shouldn't be your science project. It should enable your agility. And that comes from choosing the right tools, not building them.

Am I way off base? Is there something I’m not seeing?

Reply and let me know. I read every response.