AI consulting
Two to four weeks with the engineers who would do the work. You get a prioritised portfolio, a reference architecture, a cost model at your real volume, and a clear list of the use cases we think you should drop.
What is ai consulting?
AI consulting, done usefully, answers three questions: which of your candidate use cases will actually work, what each one costs to build and run, and which one to do first. Our engagements are run by the engineers who would build the system, take two to four weeks, and end with an architecture and a build estimate rather than a maturity model. A material share of them conclude that some proposed use cases should be dropped, which is usually the most valuable finding in the report.
Why teams call us
Almost every engagement starts from one of these. If none of them sound familiar, you probably do not need us yet.
Use cases get prioritised by which prototype impressed a leadership meeting rather than by expected return, feasibility or operating cost. The result is a programme that spends its first two quarters on the most visible use case instead of the most valuable one.
Six months of engineering against a use case with no measurable payback.
Feasibility is assumed based on what teams say about their data. Then the build starts, and the records turn out to be incomplete, contradictory across systems, or missing the field the whole approach depended on.
Discovered in week five of a build rather than week one of an assessment.
The engagement produces maturity curves and a roadmap, but no architecture, no evaluation criteria and no numbers. The engineering team receives it and has to start the analysis over.
You paid for a description of the problem, not a reduction in risk.
Cost is estimated from pilot volume. At production volume the inference bill makes the use case indefensible, and the architecture has already been built around a single expensive model.
Projects get cancelled after launch, which is the most expensive time to cancel them.
Scope
We work through your candidate list and score each on expected value, feasibility with your actual data, operating cost at real volume, and organisational readiness. The scoring is written down so you can challenge it.
We inspect samples of the real records, not a description of them, and report what would have to be fixed before a system could depend on them.
A verdict per use case, grounded in having built similar systems, including the failure modes that are specific to your domain.
A build-ready design for the prioritised use cases: components, data flow, model selection, evaluation strategy and integration points.
Per use case, not as a policy. We compare a build against the credible vendor options on total cost over two years, switching cost and strategic dependency.
What has to be true for your security, legal and compliance functions to approve the system — identified before the build rather than during review.
How it runs
Fixed checkpoints with a named deliverable at each one, so you can stop the engagement at any stage and still own something useful.
We agree the question the engagement will answer and who needs to be convinced by the output. Consulting work fails most often because the question was never made precise.
Interviews with process owners, a walkthrough of the systems involved, and hands-on inspection of real data samples.
Each candidate use case is scored, and we build the cost and latency model at your projected volume rather than at pilot volume.
A reference architecture for the top use cases, an evaluation plan, and a build estimate with risks named.
Results
Most companies do not have an AI idea shortage. They have six or ten plausible use cases, no way to compare them, and a growing suspicion that the one with the best demo is not the one with the best return.
That is the question this work answers. Not “what is our AI strategy” in the abstract, but: of these candidates, which will actually work with our data, what will each cost to run at our volume, and which do we do first.
Feasibility is a technical judgement. Whether a given process can be automated to an acceptable error rate depends on how ambiguous the inputs are, how clean the records are, how the exceptions are distributed, and how well similar systems have performed. Those are things you know from having built them and watched them fail in specific ways.
So the people doing this assessment are the people who would do the build. It makes the estimate honest — nobody is incentivised to describe an easy project they will not have to deliver.
It means we look at your records. Not a survey of how teams rate their data quality, which is consistently optimistic, but a sample of the actual rows and documents the system would depend on, checked for:
This is where projects are quietly saved. A use case that assumed a clean customer identifier across three systems, when no such identifier exists, is better discovered in week one.
Pilot economics mislead systematically. A hundred queries a day through a frontier model costs almost nothing; a hundred thousand does not. And by the time volume arrives, the architecture usually assumes one model for every step.
We model cost per transaction at your projected volume, identify which steps can run on smaller or open-weight models without measurable accuracy loss, and put that routing plan into the architecture from the start. It is far cheaper to design for than to retrofit.
Every assessment we deliver includes use cases we recommend dropping, with reasons. The recurring ones:
Clients tell us this section saves more money than the recommendations do.
Next Step
A 30-minute technical call with an engineer who has shipped this before — not a sales qualification round. You leave with a feasibility read, a rough shape for the build, and an honest answer about whether it is worth doing at all.