Skip to content
Briefs · engineeringUpdated

Build vs Buy Decision

Decide whether to build it, buy it, or partner — with eyes open.

You walk away with

A build / buy / partner recommendation with total cost and risk laid bare.

Decidi convenes

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?

Recommended level: StandardProven pro models — the everyday default.
What the council debates
Help us decide whether to build, buy, or partner for a capability we need.

THE CAPABILITY:
[what you need, and why it matters to the business]
BUILD OPTION: [rough effort, who would build it, ongoing maintenance]
BUY OPTION: [the vendors/tools, cost, fit, lock-in]
PARTNER OPTION (if any): [the partnership shape]

Debate:
1. Is this core to our differentiation (build) or a commodity (buy).
2. True total cost of building — including maintenance, opportunity cost and the forever-tax.
3. Buy risks — lock-in, vendor viability, fit gaps, integration cost.
4. Time-to-value and what each path costs us in months.
5. Reversibility — how stuck are we if we are wrong.

FINAL SYNTHESIS:
- A recommendation: BUILD, BUY, or PARTNER, with the decisive reason.
- The total honest cost of the recommended path over two years.
- The condition that would flip the decision.
What the debate sounds like

An illustrative excerpt for a hypothetical brief of this type: 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. Every real run is generated fresh from your specifics, debated across rounds, and audited before the verdict.

📊
The Strategy Consultant

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.

🏗️
The CTO

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 Dealmaker

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.

💰
The CFO

Two-year totals with the corrected estimates: build costs roughly double the vendor fees once the forever-tax is priced, and it delays the capability by most of a year. Buy on negotiated terms, and write down the flip condition: if routing becomes the differentiator the Strategy seat described, revisit with real usage data — you will negotiate the exit better knowing exactly what you need to replace.

Run this brief as a council

Prefer drop-and-go? Use the Build vs Buy Decision tool — team pre-seated, included with Plus.

Questions people ask

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.