01The three modes, clearly defined
The vocabulary is loose in this market, so let's pin it down before answering anything.
Fractional
A small embedded team — usually one to four people — runs the procurement-AI capability for you, on your tools, for a defined window. The output is value; the artefact you keep at the end is a working operating model and the in-house capability to take it over. Cost: $60–250k per quarter depending on scope. Typical engagement length: two to three quarters.
Buy
A vendor sells you a platform — typically as a multi-year subscription with implementation services attached. The output is software; the artefact you keep is whatever the platform produces, while it produces it. Cost: $200k–$2M per year. Typical lock-in: three to five years.
Build
Your in-house engineering and ML team builds the capability against your own infrastructure, your own model contracts, your own data. The output is software; the artefact you keep is everything. Cost: $400k–$3M to first production version, plus ongoing run rate. Typical timeline-to-value: six to fifteen months.
The hybrid trap
Many vendors will pitch a "hybrid" — software plus implementation services that sound fractional. Read the contract carefully. If the services end when the platform goes live, that's buy dressed up. If the services continue and the platform is incidental, that's fractional. The lock-in profile is wildly different. Don't confuse them.
02Question 1 — Is the workload core or generic?
The classic Geoffrey Moore distinction. Core work creates competitive differentiation; generic work is the table-stakes activity every desk does the same way. In procurement, the core/generic split is unusually clear:
Generic procurement workloads (about 85% of the function)
- Contract clause extraction, redlining against a playbook
- RFP first-draft generation
- Supplier news monitoring
- Spend-cube anomaly explanation
- Renewal-pipeline tracking
- PO-invoice exception handling
- Supplier onboarding document collection
Core procurement workloads (about 15%)
- Category strategy that genuinely differentiates your sourcing posture
- Pricing models tuned to your specific spend profile and supplier base
- Risk-scoring calibrated to your firm's risk appetite and historical decisions
- The negotiation playbook that captures your firm's actual negotiating posture (not a generic one)
If the workload is generic, the answer is almost certainly not build. Generic workloads are exactly what frontier-model-plus-skills-suite handles well. Build only on the core 15%, and only after you've validated the workload is genuinely core — not just feels core to the people closest to it.
03Question 2 — Do you have in-house ML/eng capacity?
"Capacity" here is specific: do you have one to three machine-learning engineers and one product manager with at least 60% allocation, available within ninety days, for an engagement that runs nine to fifteen months? Genuinely available, not "in-theory available". Most CPOs will overstate the answer to this question because they want to keep the option open.
If you don't have that capacity — and most procurement functions don't, including ones whose parent companies do, because procurement is rarely first in the queue for engineering allocation — then build is off the table this year. That's not a permanent statement; it's a this-year statement. Re-test it in a year.
The honesty test
Ask the head of engineering, in writing, this question: "If procurement requested two ML engineers and one PM at 70% allocation starting next quarter, would you fund it, and at what cost to which other roadmap?" The answer to that question — not a verbal "yes in principle" from the engineering EVP — is what tells you whether build is real. We've seen four out of five CPO desks discover at this step that build wasn't real and they hadn't realised it.
04Question 3 — Is the savings window in quarters or years?
The most pragmatic of the three questions. If the CFO has tied procurement to a savings number that lands in this fiscal year, you cannot build. Build's earliest realistic time-to-first-savings is two to three quarters, and that's optimistic — the median across the production deployments instrumented to date is four. If the savings need to land in three quarters or sooner, the choice is between fractional (3–8 weeks to first savings) and buy (typically 4–6 months to first savings, sometimes longer if implementation is rocky).
If the savings window is multi-year — you're building a structural capability the CFO is treating as an investment — then build re-enters the option set, provided the workload also passes the core test. If the savings window is multi-year but the workload is generic, you're investing in homegrown infrastructure that frontier models will commoditise inside the build timeline. That's the worst possible quadrant.
05The decision matrix
The 2×2
Three of the four cells say "don't build." The matrix is telling you something — most desks are over-estimating either their core/generic split or their engineering capacity.
| Workload | Eng capacity? | Savings window | Decision |
|---|---|---|---|
| Generic | No | This fiscal year | Fractional |
| Generic | No | Multi-year | Buy (after fractional pilot) |
| Generic | Yes | This fiscal year | Fractional |
| Generic | Yes | Multi-year | Buy — do not build generic |
| Core | No | This fiscal year | Fractional with a build-readiness brief at exit |
| Core | No | Multi-year | Fractional now, build year 2 |
| Core | Yes | This fiscal year | Fractional + parallel build |
| Core | Yes | Multi-year | Build — this is the only quadrant where build is the right answer |
A useful diagnostic: count how many of your procurement-AI workloads fall in that last row. If the answer is more than two, you are over-estimating either your core/generic split or your engineering capacity, and the matrix is telling you something you don't want to hear.
06Vendor-pitch red flags — the platform you didn't need
If you've decided buy is the right mode for a workload, the next risk is being sold the wrong kind of buy. Six things that, when they appear in the vendor pitch, mean you're being sold a platform when you needed a team:
- "Configurable to your workflows" without showing you the configuration UI. Configuration in this market is often "we'll do it in a services engagement". That's not buy. That's buy + buy.
- Three-year minimum commitment for a workload that frontier models will commoditise inside that window. Most generic procurement workloads will look meaningfully different in 24 months. A three-year lock should be a five-year-stable workload, or it's a structural mismatch.
- "Our model" without disclosing what it's based on. Most "procurement-AI platforms" are GPT-or-Claude with a domain wrapper. Fine — but you should know which, because their roadmap depends entirely on the underlying model's roadmap, which they don't control.
- Implementation timeline measured in months, value timeline left vague. If implementation is six months and value-realisation is "ongoing", the implementation cost is fixed and the value is conditional. You're paying for the wrong half.
- "We don't share benchmarks for competitive reasons." The serious vendors in this space publish their benchmarks. The vendors who don't, usually don't because their numbers won't survive contact with daylight.
- No procurement people on the founding team. AI-for-procurement is fundamentally a procurement product. If the founders are AI people with procurement advisors, the product will read that way too — technically capable, procurement-tone-deaf.
"We did a full RFP on three platforms last year and signed a three-year deal with the winner. Twelve months in, the platform's roadmap is six months behind what we can do with a fractional team plus the underlying frontier model. We can't easily get out, and we can't accelerate the platform. That deal was the worst procurement decision I've made in fifteen years." — Composite of recurring feedback from procurement leaders who locked in early on platform deals
07The typical progression — and why most desks should start fractional
The empirical pattern across the production deployments and the practitioner community: start fractional, graduate to buy on the high-volume generic workloads after twelve months, and only build on one or two genuinely core workloads after twenty-four to thirty months.
1
Fractional
You don't yet know which workloads matter enough to lock in. Fractional gives you optionality plus speed-to-value. The artefact you keep at the end is a clear-eyed view of which two or three workloads are actually high-volume and core to you.
months 0–12
2
Buy the high-volume generics
Once you know the high-volume generic workloads, the buy decision becomes safe — you're committing to a known volume on a known workload pattern. The procurement of the buy is now a real procurement (which is, awkwardly enough, also a procurement-AI use-case).
months 12–24
3
Build on the core 1–2
Whatever is left is the genuinely core, genuinely strategic work. Building here makes sense because it's no longer hypothetical — you've already done the work via fractional and you know exactly what the build target needs to be.
months 24+The reason this progression dominates is also why it's not what gets pitched. Vendors selling platforms have an incentive to skip phase 1, because phase 1 is where you find out their platform isn't actually what you needed. Engineering teams pitching build skip phase 1 because they want the work. Only fractional providers actually benefit from running phase 1 honestly — which is why honest fractional providers are willing to publish frameworks like this one, even though the framework eventually routes most clients away from them. Build the in-house capability. That's the right destination for every procurement function on a five-year horizon.
If you want to start tomorrow — the 16-skill suite is free. The override files let you fine-tune per company. That's the whole offer: no platform pitch, no consulting upsell, no implementation services. Just the skills, ready to deploy on whichever frontier model your CISO has already approved.
