The build vs. buy debate has become outdated. Most organisations frame this as a binary choice when the reality is more nuanced: modern procurement technology is modular, composable, and increasingly accessible to non-developers. The strategic question isn’t whether to build or buy but how to combine foundational platforms with custom logic to create systems that actually fit your organisation. This framework provides a clear decision path anchored in two critical questions: is this core to competitive advantage and do we have the capability to execute?
The False Binary
Procurement teams have been told for years that buying is safe and building is risky. That advice made sense when “building” meant hiring developers to write systems from scratch over 18 months. But that’s no longer what building looks like. Today’s build vs. buy decision involves three distinct paths:
Buy off-the-shelf. Select a vendor platform and use it largely as-is, with minimal configuration. [Go to Entrepreneurial Procurement to find what’s actually right for you]
Buy and compose. Use existing platforms as your foundation, then build workflows, integrations, and automation layers on top to create tailored systems.
Build from scratch. Develop custom software with internal or contracted engineering teams.
The interesting territory is the middle option. It’s where most of the strategic value now lives, and it’s often faster and cheaper than either extreme.
What “Building” Actually Means Now
When procurement professionals discuss building, they’re rarely talking about writing code from scratch. Modern building looks like this:
- Using low-code or no-code platforms to create custom workflows
- Integrating best-of-breed tools through APIs
- Automating processes with platforms like Workato, Make, Zapier or n8n
- Extending SaaS systems with lightweight customisation
- Composing solutions from modular components
This approach offers genuine advantages:
Speed. Some teams have replaced €30,000p.a. vendor platforms with composable solutions built in days for under €1,000 annually. The economics aren’t hypothetical.
Flexibility. As your procurement function matures, you can adapt systems without waiting for vendor roadmaps or paying for enterprise upgrades.
Avoiding vendor lock-in. When you control the integration layer, you’re not trapped by a single platform’s limitations or pricing strategies.
Fit for purpose. You only build what you actually need, rather than paying for features you’ll never use.
This is the model I’ve used successfully, as detailed in my earlier analysis on customising existing tech and budget procurement approaches. The key isn’t avoiding vendors entirely but using them as building blocks rather than complete solutions.
The Two Questions That Matter
Joël Collins from Pure Procurement has developed a decision tree that maps the build vs. buy logic clearly.
What’s valuable about his framework is that it recognises two foundational questions that dictate everything else:
1. Is this capability core to your competitive advantage?
If this doesn’t differentiate you strategically, the case for custom development weakens substantially. But “core” doesn’t mean you must own every line of code. It means the capability matters enough to warrant investment in tailoring it properly.
2. Do we have the required technical expertise?
This is where most organisations misjudge themselves. They assume “technical expertise” means having software engineers on staff. In reality, it increasingly means having people who understand systems thinking, process design, and how to leverage modern automation platforms.
If you answer “no” to the first question, buying a standard solution usually makes sense. If you answer “yes” to both questions, some form of building (whether composable or custom) becomes viable.
Everything else in the decision tree flows from these two points: resource availability, total cost of ownership, time to market, strategic control. Those factors matter, but they’re secondary. Get the first two questions right, and the rest clarifies quickly.
The Case for Composability
The procurement technology landscape has fragmented in useful ways. You no longer need to choose between “build everything” or “buy a monolithic platform.” Instead, you can:
Start with proven infrastructure. Use established platforms for data storage, authentication, and core functionality. Don’t reinvent databases or security protocols.
Build your differentiation layer. Create the workflows, integrations, and automation that reflect your organisation’s specific processes. This is where competitive advantage actually lives.
Maintain control of the logic. When you own the integration and workflow layer, you can swap out underlying tools without rebuilding everything.
When Buying Makes Sense
Buying still has clear use cases, particularly when:
The market has solved it well. For genuinely commoditised processes where differentiation offers no advantage, standard solutions work fine. Basic contract repositories, simple approval workflows, and standard reporting often fall into this category.
Speed matters more than fit. If you need a capability running in weeks and customisation isn’t critical, off-the-shelf platforms deliver faster.
You lack process maturity. Early-stage procurement functions often benefit from adopting proven structures that vendor platforms provide. You can customise later as you understand your needs better.
The economics strongly favour it. Some vendor platforms genuinely offer better total cost of ownership, particularly when support, maintenance, and upgrade costs are factored in.
But here’s the nuance most frameworks miss: even when you buy, you should still build on top of it. No vendor delivers 100% of what you need. The gap between “good enough” and “actually fit for purpose” is where real value gets created.
The Economics of Building
Total cost of ownership calculations typically favour buying because they assume building means hiring engineering teams. That assumption no longer holds.
Modern composable building involves:
- Subscription costs for automation platforms
- Integration tools with transparent pricing
- Time investment from procurement team members who understand the processes
- Occasional external support for complex technical problems
Compare this to enterprise procurement platforms where:
- License costs start at €50,000+ annually
- Implementation fees can match or exceed annual licensing
- You pay for features you don’t use
- Customisation requires vendor professional services at premium rates
- Price increases arrive annually without corresponding value increases
The numbers won’t always look this extreme, but they’re stark often enough that procurement leaders should challenge the idea that buying is automatically cheaper.
It usually comes down to capability. If you have the skills to build using modern composable tools, the economics can tilt in your favour.
A Balanced Framework
Rather than defaulting to “buy unless exceptional,” procurement teams should approach this decision neutrally:
Stage 1: Strategic assessment Is this capability core to competitive differentiation? If yes, continue. If no, evaluate commercial options first, but don’t rule out lightweight customisation if vendor solutions are poor fits.
Stage 2: Capability check Do we have (or can we develop) the expertise to build using modern composable tools? This doesn’t require software engineers. It requires systems thinkers who can design workflows and leverage automation platforms. If yes, building becomes viable. If no, assess whether you can hire this capability or partner externally.
Stage 3: Market evaluation What commercial solutions exist, and how well do they fit? If something meets 80-90% of requirements at reasonable cost, buying makes sense. If solutions are bloated, expensive, or poor fits, building (in the composable sense) deserves serious consideration.
Stage 4: Economic analysis Model total cost of ownership for both paths over 3-5 years. Include licensing, implementation, maintenance, opportunity cost, and customisation needs. Modern composable builds are often cheaper than assumed, particularly when vendor platforms require heavy customisation anyway.
Stage 5: Hybrid evaluation Can you buy foundational infrastructure and build the differentiation layer? This is often the optimal path: vendor platforms for commodity functions, custom logic for what matters strategically.
The Real Innovation Layer
Here’s what gets missed in most build vs. buy frameworks: the innovation doesn’t happen in the infrastructure layer. It happens in the customisation, integration, and workflow automation you build regardless of your vendor choices.
Whether you buy Coupa, SAP Ariba or any major platform, you’ll still need to:
- Integrate with your ERP, finance systems, and internal tools
- Build approval workflows that match your organisation’s structure
- Automate data flows between systems
- Create reports and dashboards that answer your specific questions
- Develop processes that reflect your procurement strategy
That work is what I call, buying your IKEA shelve and assembling it after arriving home. The question is whether you do it on top of an expensive vendor platform with limited flexibility or on top of more modular infrastructure that you control.
The Bottom Line
The build vs. buy decision has evolved beyond simple binaries. Modern procurement technology is modular enough that most organisations should be doing both: buying foundational platforms and building tailored systems on top.
Buy when: Commercial solutions fit well, provide genuine value, and don’t constrain your strategic flexibility unreasonably.
Build when: You need differentiation, have the capability to execute using modern composable tools, and the economics make sense.
Do both when: You need vendor infrastructure for commodity functions but must tailor processes to fit your organisation’s specific needs (which is almost always).
Stop framing this as build versus buy. Start asking: what should we own, and what should we rent? Where does competitive advantage actually live, and how do we ensure we control it?
The organisations that answer these questions clearly and chart their own course rather than defaulting to vendor platforms will have more flexible, cost-effective procurement systems that actually support their strategy.
Ready to Chart Your Own Course?
If you’ve read this far, you’re probably not looking for permission to follow the herd. You’re trying to work out whether your organisation should buy a platform, build something custom, or take the composable path somewhere in between.
The honest answer: it depends on your specific circumstances. But you already knew that.
What you might not have is a practical starting point. If you’re leaning towards the composable approach or want to test whether your existing tools can deliver more than you think, I’ve put together a tactical guide that walks through the first 6 months of building a procurement function using what you already have.
Download: DIY Procurement Process Builder. A week-by-week playbook for SMEs and mid-market teams who want to start processing better today, not in 8 months.
It’s particularly useful if you’re a procurement team of 1-10 people, you have some technical capability in-house (or can borrow it), and you’re tired of waiting for vendor implementations that never quite fit.
And if you’ve already gone down this path (or taken a completely different approach that’s working) we’d like to hear about it. The build vs. buy question doesn’t have a single answer, but it benefits from more honest case studies and fewer vendor presentations.
Connect on LinkedIn and drop a message with your experience. What did you build? What did you buy? What would you do differently?