Build vs. Buy in Procurement Technology: The AI Edition

AI has made building software look easier… but easier to start doesn't mean smarter to own. Here's the definitive practitioner's guide to the Build vs. Buy debate in the age of AI procurement agents.

Your CIO just walked in with a new idea. You're not going to like it.

AI is supposedly changing everything… And now the Build vs. Buy debate in procurement technology is back from the dead, this time wearing a shiny new large language model as a disguise. I've been watching this resurface in boardrooms, Slack channels, and webinar panels across the industry, and I have to be direct with you: the fundamental answer hasn't changed one bit.

Build vs. Buy in procurement technology has always been a conversation about strategy, resource allocation, and core business focus. AI doesn't rewrite those rules. It just gives your IT department a new, pretty compelling argument…

This article is going to settle it… Once and for all, for the AI era. We'll walk through the full continuum of options actually available to you, five real-world scenarios that test the decision under pressure, a TCO reality check that includes the numbers nobody puts on the slide, and a clear verdict on when (and only when) building makes any sense at all.

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

For most businesses, their "core business" is tied to their industry: banking, manufacturing, professional services, retail. It's the primary activity that allows them to create value for customers, generate revenue, and build margin through a genuine competitive advantage.

And here's the thing: most businesses have serious trouble just doing that well at scale.

Revenue targets get missed quarter after quarter. Executive shuffles happen every 18 months. Retention issues that HR can't solve. Projects that run over budget and under-deliver. Last time Bain checked, 88% of digital transformations fail… And that's just for adopting technology. Not building it from scratch.

Most organizations 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?

Here's the problem with how this debate usually gets framed: it treats Build and Buy as two discrete options sitting across a table from each other. Your CIO is on one side. Your CFO is on the other. Someone wins.

That's not how this actually works.

Build vs. Buy in procurement technology is a continuum. Where you land on it determines how much risk, cost, and maintenance burden your team absorbs. Most organizations anchor to the extremes and miss the better positions in the middle.

Here's what the full spectrum actually looks like:

"Build vs. Buy" is a continuum, not a binary question. The smartest procurement functions have already figured this out… You might also have different portions of your tech solutions on different parts of the continuum in the same organization, based on context… (e.g. Co-Pilot does the trick for scenario A but not scenario B, which requires a fit-for-purpose solution to get desired results).

Leading procurement teams aren't choosing between building and buying. They're doing both… In the right sequence and at the right layer.

The model looks like this: Buy the platform. Use the pre-packaged agents as your starting point. Copy and modify them to fit your context. Build from scratch only for the edge cases that genuinely require it.

This is "Buy to Build" and it changes the math entirely.

You get the vendor's infrastructure, security posture, compliance certifications, LLM integrations, and maintenance burden off your plate. But you retain the ability to configure deeply, extend intelligently, and (when truly necessary) build something custom on top of a foundation that's already production-ready.

Think of it the way a “good olde ERP implementation” works. You're not re-engineering the core system. You're configuring it, extending it with custom workflows, and occasionally building bespoke integrations where the standard connectors don't reach. The platform does the heavy lifting. Your team handles the nuance.

The difference with “AI era solutions” is that the old ERP is clunkier than you great aunt dancing in a pair of clogs… 😅 Building ERP extensions has been a way of life so far!

But before you build anything, the first question should always be: what's already available in the platform you're already paying for? Pre-packaged agents that you can activate, test, and modify are almost always the right starting point before any custom development conversation begins.

Building from scratch? That's still on the table! But only for organizations genuinely ready to absorb every risk, cost, and maintenance obligation that comes with full ownership. Which we're about to spend some real time on.

I want to spend real time here, because the underestimation is staggering.

If you're going to build software in-house (AI-powered or otherwise), you're planning to add software development to your core business. Permanently. You're dedicating a non-negligible amount of resources to development and maintenance indefinitely. Because here's what nobody tells you: developing software that supports important business processes creates lock-in of your most precious resources.

Let's be specific about what that actually means in practice:

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

Properly developing and maintaining software is a skill. 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 founders who studied computer science, teams dedicated solely to development, exposure to use cases across industries and geographies, and venture capital backing to sustain them through cycles.

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 ChatGPT 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:

The AI engineering talent market has a 3.2:1 demand-to-supply ratio, meaning for every AI engineer available, there are more than three open positions competing for them. You are not just competing with other procurement teams for this talent. You are competing with Google, Meta, OpenAI, and every well-funded startup in the world.

For AI agents specifically, you don't just need developers. You need people who understand Large Language Models, prompt engineering, RAG pipeline architecture, MLOps, and procurement domain logic simultaneously. That's a very small Venn diagram.

There's another important concept in software engineering called the "bus factor"… A measurement of how many key people would need to leave (or be hit by a bus… 😅) before your system becomes unmaintainable. For most internally-built procurement tools, the bus factor is exactly two. Sometimes one.

When that developer leaves (and they will leave eventually, because they're highly marketable) you own a system that nobody fully understands anymore. The documentation is incomplete. The logic is tribal knowledge. And now you're paying a consultant three times the original salary to reverse-engineer your own system.

This isn't hypothetical. It plays out constantly across the industry.

I get it. The attractiveness of building your own software ultimately boils down to control. You get to develop in any direction you choose, according to your own priorities, without needing to lobby a vendor and jostle against other customers' feature requests.

That sounds appealing. It really does.

But that control is an illusion.

You're still jostling for priorities… Just internally. Every department wants something different. Every executive has their own vision. Every user has their own workflow. You're still constrained by budget, by available developer time, by technical limitations, by the skills on your team. And you're still dependent on key personnel who understand the codebase, on vendors for infrastructure and tools, and on open-source libraries maintained by strangers.

The "control" you gain is narrower than you think. The burden you take on is larger than you expect. And the best procurement platforms today give you genuine configurability (workflow engines, rule builders, approval matrices, custom fields, extendable APIs, etc.) without asking you to become a software company to get it.

Theory is easy. Let's stress-test this against real procurement situations.

A global services company has developed highly specialized sourcing processes for professional services. Their CPO believes a custom AI agent could widen their cost advantage. Their CIO wants to build it.

The real question: Can your internal team out-innovate a vendor whose entire business is shipping agent improvements every week? Almost certainly not. Unless your sourcing process is genuinely the reason clients choose you over competitors (which for 99.9% of companies, it isn't) the competitive edge argument doesn't clear the bar.

A regulated multinational wants AI agents for supplier risk monitoring. The procurement director wants to build for compliance control. Finance wants the accountability of a vendor contract.

Here's what the build-for-compliance argument misses: leading AI compliance frameworks mandate automatic logging and traceability for high-risk AI systems. Certified vendors deliver this out of the box, with SOC 2 Type II, GDPR, and ISO 27001 compliance pre-audited. Building this internally is not a configuration project. It's a compliance engineering project… With annual recertification requirements and real legal exposure if you fall short.

The "control" of building internally often becomes the "liability" of owning a compliance posture your team wasn't designed to maintain.

A global company needs to roll out AI intake agents across 40 countries. The internal team has only ever deployed tools regionally.

Scaling from regional to global isn't a bigger version of the same problem. New regions mean new cloud zones, new observability pipelines, new data residency requirements, new languages, new ERP integrations, new compliance frameworks. This requires dedicated MLOps, 24/7 incident response, and infrastructure expertise that most internal procurement IT teams simply don't have.

Regional experience does not scale to global operations automatically. Vendors have already figured out how to do this across dozens of clients. You are about to figure it out for the first time.

A fast-growing company has a backlog of low-value purchase requests growing daily. A vendor can deploy in eight weeks with 80% use case coverage. Internal IT says they can build something with 95% coverage in six months.

And here's what that math misses: prototyping is not production. The internal team's six-month estimate is for the prototype. Production-ready agents require security hardening, RAG pipelines, workflow orchestration, monitoring, error handling, and policy logic. You're not six months from done. You're six months from starting.

Meanwhile, the backlog grows. And the 20% gap the vendor can't cover? That's where you configure, extend, or use adjacent tools. It's a solvable problem. A six-month delay isn't.

A company built a custom AI agent for spend analytics two years ago. It's now central to their strategy. The architect just gave notice. One of the two remaining developers is interviewing elsewhere.

This is not a hypothetical. This is Tuesday.

The counterargument (that you should just invest more in team depth) is valid in theory and almost never executed in practice. Because the moment you hire to cover the departing architect, the budget conversation becomes: "Why are we spending this much to maintain something a vendor would support for a fraction of the cost?"

The bus factor was never calculated. The total cost of ownership was never honestly modeled. And now you're exposed.

This is the number that never makes it to the Build side of the cost comparison.

When you build, you pay for initial development + ongoing salaries + infrastructure + security + compliance + maintenance + documentation + knowledge transfer + talent retention premiums + opportunity cost of your management team's time.

When you buy, you pay for a subscription fee.

The subscription feels expensive until you put those two lists side by side with actual numbers. For AI-specific tooling, you're looking at $200,000–$400,000+ annually in fully-loaded engineering costs before you've shipped a single feature to production… for a team small enough where the bus factor is already a problem.

The build argument almost never survives honest five-year TCO modeling. Which is exactly why it's rarely done before the decision gets made 😅

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

Building in-house makes genuine sense for:

And even then… With a good platform, you can often build all of the above on the platform itself. Which means you get the flexibility without inheriting the full infrastructure burden.

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 these questions before anyone touches a keyboard:

If the answers are uncomfortable, you already have your answer.

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 to you.

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.

A gust of wind comes along, you start over with new cards. It rains, you throw away the soggy ones and start fresh. A Dorito gets thrown at your castle and collapses a tower, you rebuild… (If you know, you know… 😅)

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.

Asking whether to build your own procurement platform is a bit like asking: should we grow our own coffee beans, roast them, and brew our own coffee for the office? Or just buy coffee from someone who does it for a living?

You'd think that's ridiculous. And you'd be right. The same logic applies to your procurement technology.

Buy the right platform. Configure it. Extend it where necessary. Use the "Buy to Build" model to get the control you want without the burden you don't need. And put your energy where it actually matters: your procurement strategy, your supplier relationships, your people, and your core business.

That's the competitive advantage. Not the code.

See you next week,

— Joël Collin-Demers

P.S. Please rate today’s newsletter.
Your feedback shapes the content of this newsletter.

First time reading? Sign up here