Build vs Buy Decision — by an AI council
Decide whether to build it, buy it, or partner — with eyes open. Four rival AIs debate it and hand back: A build / buy / partner recommendation with total cost and risk laid bare.
A build / buy / partner recommendation with total cost and risk laid bare.
Signed off by an independent Final QA audit — with a “verify before you rely on this” list, never a black box.
Why this team
Build-versus-buy is decided by costs nobody writes down: the engineer’s optimism about build time, the vendor’s silence about integration pain, the forever-tax of maintaining what you built. The CTO and Software Architect estimate the build honestly, the CFO totals both paths over two years rather than one budget cycle, the Dealmaker reads the vendor’s contract and lock-in the way vendors hope you will not, and the Strategy Consultant asks the only strategic question: is this capability how you win, or just how you operate?
Each seat runs on a different frontier model — GPT, Claude, Gemini, Grok — so it’s a genuine cross-model review, not one AI in costumes. How a run works →
What the debate sounds like
An illustrative excerpt — A logistics scale-up needs route optimisation; the engineering lead estimates a build at four months, and the leading vendor quotes an annual fee with a per-vehicle component and a two-year term.
First establish which kind of capability this is. If route quality is how this company wins deals — if customers choose you because your routes are tighter — it is differentiation and the build case deserves the hearing. If it just needs to be as good as everyone else’s, it is a commodity wearing a strategic costume, and commodities get bought.
On the four-month estimate: routing is a deceptive domain — the demo works in month one, and then real-world constraints arrive: driver breaks, time windows, vehicle capacities, traffic. Double the estimate and add a permanent half-engineer for maintenance, because optimisation is never done. The honest build price is eight months plus a forever-tax, and I say that as the person who would enjoy building it.
The vendor quote has two teeth worth negotiating before any decision: the per-vehicle component means the price scales exactly with your growth — your success is their upside — and the two-year term with auto-renewal is longer than your planning horizon. Ask for a one-year term and a volume cap. How they respond tells you what kind of partner they are.
Questions
What numbers should I bring for a fair comparison?
The build estimate from whoever would build it (the debate will stress-test it), rough engineering cost, the vendor quote with contract term and pricing structure, and your growth expectations — since usage-based vendor pricing changes the maths as you scale. Missing numbers get flagged, not invented.
The council doesn’t know my vendor — how can it judge the buy option?
It judges the structure of the deal, which is where buy decisions actually go wrong: lock-in terms, pricing that scales against you, integration cost, data portability at exit. Paste the actual quote or contract terms and the Dealmaker seat reads them the way procurement should but rarely does.
What if the answer is genuinely close?
The verdict still commits — BUILD, BUY or PARTNER — but a close call produces the most useful artefact: the flip condition, written down. “Buy now, revisit if X” converts an agonised decision into a monitored one, which is how close calls should be held.
Your material is used only to run your review — never to train public models. Encrypted in transit and at rest. Security & privacy →
Want full control — pick your own minds, set the depth? Open the full council →