When should you build custom procurement software and when should you buy it?
Building makes sense when the process is a genuine competitive advantage, when there is a regulatory or intellectual property requirement no platform covers, when the scope is narrow and stable, or when a team already exists that will maintain it across the full useful life of the system. Buying makes sense when the process is standard — purchase orders, catalogs, approvals, supplier documentation — when a regulatory date is involved, or when the engineering team has a use that differentiates the business more.
What is the buy-and-extend model?
It means acquiring a commercial platform as a standard core and building on top of it, through APIs or advanced configuration, only the part of the process that is genuinely yours. It avoids both bad versions of the problem: forcing a complex process into a rigid standard, or building everything from scratch. It demands more discipline than the other two routes, because every extension of your own is debt of your own: without governance it ends up blocking vendor upgrades and becomes a disguised custom build.
How do you calculate the TCO of procurement software?
By adding up the full lifecycle, not the project: licenses or subscription, implementation and configuration, ERP integration, infrastructure, training and change management, support, and functional evolution year after year. For custom development, add corrective maintenance and the cost of team turnover; for a commercial platform, renewal increases and consumption-based charges. The comparison is only valid if both routes are calculated over the same horizon.
Is building cheaper than buying a license?
Across the full lifecycle, almost never, because the correct comparison is not license against project but the total cost of both routes over the useful life of the system. That said, there are cases where building is cheaper: a small and stable scope, a team already on payroll that would not be freed for anything else, and an existing platform where the piece can live without new infrastructure. The way to know is not intuition: it is calculating both routes over the same horizon and the same cost categories.
How do I avoid getting locked in with a vendor?
Dependency is not eliminated, it is negotiated and bounded. In the contract: data ownership, export in a usable format, notice periods and renewal terms known from day one. In the architecture: integration through standard APIs rather than deep coupling, and your own extensions documented and separated from the core. It is worth remembering that building also creates dependency, only on specific individuals instead of a contract — and that one is harder to replace.
How does artificial intelligence affect the build versus buy decision?
It pushes in both directions. General-purpose models substantially lowered the barrier to building narrow pieces that used to require a long project. At the same time they raised the cost of keeping them alive: data governance, continuous evaluation of output quality, model versions that change, and human review before a result is applied. The useful question is not whether you can build an agent, but who evaluates it every month and against what criteria.
What does a business case need for Finance to approve it?
The problem with evidence and a cut-off date; the alternatives compared, including doing nothing; the benefits with their calculation base, owner and confidence level; costs broken out by year and by type; the assumptions declared as assumptions, with who validates them; and the payback, ROI and NPV calculation over an agreed horizon. The template that accompanies this guide carries that structure across ten sheets.
