Consulting Desk · Build, Buy or Partner Review
Build it, buy it,
or partner for it.
Usually not build.
One capability, costed three ways on the same basis, with the assumptions each route turns on written down. Runs as an Advisory Sprint — fixed fee, no code, and a recommendation to buy something off a shelf is a completed engagement.
You hold: a written position, three routes costed on one basis, over one period and the assumptions each route depends on, named individually.
Why the answer is usually buy
If it can be bought, buy it. Spend your people on the part nobody has solved.
That is the rule we run our own firm on, and it is the rule we bring to yours. Most AI capability an organisation wants is now a product someone else maintains, evaluates and patches. Building it yourself buys you a maintenance obligation and a hiring problem, and it rarely buys you an advantage.
The exception is the part of the problem that is actually yours — your data, your process, your regulatory position, the thing no vendor has met before. That part cannot be bought, and it is where a build earns its cost. Most reviews end with a short build list and a longer buy list, which is the right shape.
Partnering is the route people skip. Where the capability is real but the appetite to own it is not, someone else can run it under a contract that names the service level and the exit. That is a legitimate answer and it gets costed alongside the other two rather than mentioned in passing.
We are not a neutral party, and we say so
We build AI systems for a living, so a review that says buy costs us the build. That is exactly why this shape is contracted the way it is: fixed fee, agreed before we start, and no code in scope. If the honest answer is a product you can buy this quarter, we would rather write that down than win the work.
How it runs
One capability, three routes, one basis for comparison.
The comparison is only worth having if the three routes are costed the same way — over the same period, including the costs people leave out. Two to three weeks, fixed.
- EngagementAdvisory Sprint
- Duration2–3 weeks, fixed
- MethodThree routes costed on one basis, over one period
- GateEvery route carries its total cost of ownership, not its licence fee
- BuildsNothing — this shape produces a written position
The capability, named narrowly
Not “document processing” but the specific job, its volume, its accuracy requirement and who is accountable for its output. A review pointed at a category produces a category-shaped answer.
The market, as it actually is
What can be bought today, what is on a roadmap, and what is being marketed as existing but is not. Where a vendor claim cannot be verified, it is recorded as a claim with an evidence state, not as a capability.
Three routes, one basis
Build, buy and partner costed over the same period, including the costs that get left out: evaluation, monitoring, the people who maintain it, and what it costs to stop.
The assumptions each route turns on
Every route depends on something being true — a volume, a price holding, a vendor surviving, a hire landing. Those are named, because the decision is really a bet on them.
The recommendation, with its alternative
One route recommended, the runner-up named, and the condition that would change the answer. Written to be read by a board and defended six months later.
The two lists that matter
What you hold, and what we will not do.
Both are in the engagement letter before you sign it. The second list is the one worth reading twice — it is where most disappointment in this market actually comes from.
What you hold at the end
- A written position, with an evidence state on every finding
- Three routes costed on one basis, over one period
- The assumptions each route depends on, named individually
- A recommendation with its alternative explicitly named
- The vendor claims we could not verify, listed as unverified
What we won’t do
- Comparisons where the build option is costed more generously than the rest
- Vendor claims repeated as capability because a vendor made them
- Recommending a build we would then be the obvious firm to deliver
- Licence-fee comparisons dressed up as total cost of ownership
- A review that cannot name the capability it is deciding about
Where it usually goes next
A build list this short is worth testing before it is funded.
Where the review does end in a build, the next step is rarely a production build. It is a Feasibility Sprint against an agreed evals harness — because the part nobody sells is also the part nobody has proved. Where the decision is about the AI you already run rather than something new, an estate review is the cheaper first move.
See the Feasibility Sprint →It can end in nothing
“Buy this, and do not staff a team for it” is a completed engagement, and so is “not this year”. Both discharge the sprint in full.
Before you commit
Whether a firm that builds can honestly tell you to buy.
You build for a living. Will you recommend a build?
We build for a living, so a recommendation to buy costs us the work. That is exactly why the fee is fixed, agreed before we start, and no code is in scope. Most reviews end with a short build list and a longer buy list.
How are the three routes costed?
Over the same period and on the same basis, including the costs that get left out: evaluation, monitoring, the people who maintain it, and what it costs to stop.
What happens to vendor claims you cannot verify?
They are listed as unverified claims rather than as capability. A plan built on a vendor’s roadmap is a bet on someone else’s delivery, and it should be visible as one.
Bring us the capability you keep re-scoping.
Thirty minutes with a founder. If the honest answer is that you should buy something and spend your people elsewhere, we will say so — and we will tell you what to buy.
Fixed fee · Quoted in writing before we start · NDA available