"Three years of AI spend, and the business case for most of it was written against numbers that have all moved."
Sanctioned tools and the unsanctioned ones people adopted without asking. The periphery gets priced quickly: seats, utilisation, and what would actually be lost without it.
Core splits two ways. Committed cases arrive with a business case behind them, usually written against inference costs, model capability and build effort that have all moved since. Candidates arrive with nothing, and often have not been proposed at all. They show up as manual effort somebody stopped noticing, data that already exists and is not used, or a workflow doing the job a system should. Unsanctioned adoption is worth reading closely here, because nobody built a business case for it and some of it points at a case worth making.
Both go through the same three phases from here. The difference is that one is being re-run and the other is being built.
Per case: which fields, at what granularity, over how much history, refreshed how often. Then whether you hold it, whether it joins, whether the lineage is traceable, and whether you are permitted to use it for this purpose. Each case gets a verdict rather than a score: ready, ready after specified work, or not viable as scoped.
Unit economics at real volume rather than at pilot scale, including the cost of clearing whatever the data check turned up. Build, buy or partner is priced here rather than assumed, because at current model pricing that answer has flipped for a lot of cases, in both directions.
The vendor question is priced across both decisions rather than each on its own. Standardising at the periphery for integration reasons narrows what the core decision looks like later, and a core vendor will usually want the seats as part of the deal. That coupling is a real cost or a real saving, and it is normally left out of both business cases.
The model layer is priced as a choice rather than a given. Frontier, open weight, and routing across several depending on the task carry different cost floors and different switching costs, and smaller models running closer to the workload are changing what the floor looks like. A case that only works at the current price of one provider's frontier model has a dependency in it, and that gets named.
Where the advantage accrues gets stated. Sending the workload to a frontier provider buys capability per token and leaves the data, the workflow and the accumulated learning on the other side of the boundary. That is a fair trade for some cases and a poor one for anything meant to be defensible. Running open weights costs more and keeps the improvement inside the business. The choice between them is economic, not a technical preference.
Then run it forward on the assumption the capability becomes ordinary, because margin built on a capability gap behaves differently from margin built on switching costs or proprietary data.
A stated view on how long the advantage holds and what erodes it, with the assumptions written down so they can be argued with. Then what would extend it. That is normally a data or workflow position, not a model one, and it comes with a cost.
Across the portfolio that resolves into what continues, what stops, what restarts on different assumptions, and what should be left undecided for now with a stated trigger for revisiting it.
The weighting shifts by client. Where nobody knows what is running, most of the work is the first phase. Where AI has been in the product for years, discovery takes a week and the whole argument is durability.
The common finding is that the advantage is real and shorter-lived than assumed, and that the largest line in the business case is getting the data into shape. It is a less exciting answer than the market rewards, and worth having before an investor asks it for you. This is the analysis behind a no-go I recommended on a pre-IPO round, where the price assumed a lead unlikely to last the hold.
A view on whether the case holds, with the economics behind it, in a form that survives challenge from someone who would prefer a different answer.
The model stays with you and can be re-run as costs move. Inference pricing and capability both move quickly, so last year's answer will not hold.
In scope: what is running and where it sits, what each core case requires and whether you hold it, the economics at real volume, which model layer each case should run on and where the advantage accrues, how long the advantage holds, and what would extend it.
Out of scope: building the pipelines, technical audit of the models, and selecting tooling. Acceptable-use policy and authorisation sit with you; this maps what is running and what it is worth, it does not write the rules. This tells you whether to commit and at what cost; the build sits with your engineering or a vendor.
Fixed price, not a day rate. The scope is agreed up front and the price does not move with it. If the work takes longer than expected, that is my problem rather than yours, which is the right way round.
Quoted after a short call, once I understand what you are actually dealing with. Invoiced half on start and half on delivery.
Timing is agreed on the call. It depends on scope, and I would rather set it against the date you are working to than quote a standard length. There is no discovery phase, so the first useful output comes early.
Most engagements end at delivery. Some clients keep me on a light retainer afterwards to keep the model current and to be available when the board asks something new. That is agreed at the end, not the start.
Where AI does part of the work, I say which part. Some of the analysis and model building uses AI tooling. The judgement, the method and the conclusions are mine, and I will tell you which is which if you ask.