AI strategy
AI consulting that ends with two or three cases worth building
The board asked for AI, two pilots did not ship, and every vendor deck says the same thing in a different typeface. We spend ten days measuring what the work costs you today, shortlist the places where a model changes that number, and say for each one whether to build it or buy it. You end with a memo your own engineers can argue with and one delivery scoped with a date and a price against it.
10 days, most of them spent measuring what happens now
The vendor comparison is struck through on purpose: a tool shortlist without a baseline moves the argument to a different meeting rather than settling it.
Ambition
A board mandate, pilots that never shipped, data nobody has labelled.
- board asks for AIno target
- pilotsnever shipped
- dataunlabelled
- vendor deckscompared
Shortlist
Two or three cases with today's numbers, a build-or-buy call each, one scoped delivery.
- shortlist2–3 use cases
- baselinemeasured today
- build/buy callper case
- first deliveryscoped
10 days, most of them spent measuring what happens now
How the work goes
- 01days 1–2
Find where the minutes and the money go
Interviews plus whatever can be counted: ticket volumes, handling times, error rates, rework. Half the value of this step is that the numbers usually turn out to be news internally.
- 02days 2–4
Sort candidates by whether they can be checked
A case with a recorded right answer can be evaluated. One without becomes a matter of opinion the moment it ships, so it goes to the bottom of the list however good it sounds in the room.
- 03days 4–7
Build or buy, case by case
For each shortlisted case: what a product costs, what building costs, what you own afterwards. We build software for a living, so we make ourselves name at least one case where buying wins.
- 04days 7–10
Scope the first delivery
One case, with an eval set, a baseline, a date and a price. Small enough that failure is survivable, real enough that success proves something to the people who approved the budget.
What the platform does, what a person does
| What the platform does, what a person does | Who does it | Notes |
|---|---|---|
| Reading your systems for feasibility | Platform | What data exists, where it sits, and whether it can be reached from where the work happens. |
| Measuring the baseline | Both | Extraction is mechanical. Agreeing what counts as an error is a conversation with the people doing the job. |
| Ranking the candidates | Engineer | By whether the result can be checked after it ships. |
| The build-or-buy call | Engineer | Judgement, with our conflict of interest stated in the same paragraph as the recommendation. |
| Data readiness | Both | The platform reports what is there. A person estimates what making it usable will cost you. |
| The memo | Engineer | Four to eight pages, written to be argued with by your own engineers. |
Why the advice is worth ten days
We are the people who then build the thing, and dozens of migrations and more than ten years of legacy work sit behind every recommendation in the memo. The estimate in it is one we have to stand behind afterwards rather than a range copied out of an analyst report. When we say a case is a three-week build, it is because we have built one.
Take the first two days on their own if you want a smaller start. If the baseline we come back with tells you nothing you did not already know about your own operation, you have spent two days rather than a quarter.
Questions we get from engineers
- You build things. How is your advice not sales?
- It is not neutral and we do not claim it is. What we do instead is state the conflict in the memo, name at least one case where buying beats building, and price the first delivery separately so the memo is worth taking to somebody else.
- Do we need a data platform before any of this?
- Usually less of one than you were told. Most first cases need a few years of records and a way to read them, not a warehouse programme. A warehouse programme is a reliable way to spend a year and a half before finding out whether the case works at all.
- Our pilots keep dying after the demo. Why?
- Almost always because nobody defined what correct looks like before building, so the pilot cannot be evaluated and has no route to production. Step two exists to stop that happening a third time.
- How is this different from your assessment?
- The assessment reads a codebase and plans a rewrite. This one reads a business process and decides whether a model helps. Companies with an old system and an AI mandate often need both, usually in that order, and we run them back to back.
- Who do you need from our side?
- Someone who owns the process and someone who can approve budget, about three hours each. This is not a workshop and we do not need your leadership team in a room.
Ask us where to start
Two things get us moving: what the board actually asked for, and which processes eat the most hours. We come back with what the review covers and what it costs.
An engineer replies, usually asking what you can already measure.