AI Consultant | Strategy, Feasibility & Build vs Buy

The expensive mistake in AI is not picking the wrong model. It is spending two quarters building something that was never going to work, or buying a platform that solves a different problem than the one you have. This is a short, deliberately unglamorous engagement to establish what is worth building before the budget is committed.

Why an independent view helps

Almost everyone advising you on AI has an incentive attached: a platform licence, a seat count, a long implementation contract. I build these systems, which means I know what they cost to run and where they break — and I have no product to place.

That includes being willing to conclude that the answer is a better search index, a fixed workflow, or fixing the underlying data. Several of these engagements have ended with a recommendation not to build the AI feature at all, which is a cheaper outcome than discovering it six months in.

What gets assessed

For each candidate use case:

Is the information even there? — most failures trace back to source content that is missing, contradictory, out of date or locked in formats nobody can parse.
What does "correct" mean, and who decides? — a use case where nobody can define a right answer cannot be evaluated, and therefore cannot be safely improved.
What is the cost of being wrong? — this sets how much human oversight the design needs, which drives most of the build cost.
Does it need a language model at all? — a meaningful share of AI requests are better solved by search, rules or a data fix.
What will it cost per month at real volume? — modelled on your actual traffic, not a per-request price in isolation.
Who owns it afterwards? — a system nobody on your team can maintain is a liability regardless of how well it launches.

Build, buy or wait

Three legitimate answers, and the third is underrated. Buying makes sense for commodity capability where your requirements are ordinary and integration is shallow. Building makes sense where the workflow is genuinely specific to you, where data cannot leave your environment, or where the capability is close enough to your core value that outsourcing it is strategically awkward.

Waiting makes sense more often than vendors suggest. If a capability is improving quickly and is not urgent, six months of patience can turn a difficult custom build into a configuration exercise. The assessment says which of the three each use case is, and why.

Data, privacy and regulatory constraints

These constraints shape the architecture more than any technical preference, so they are established early: what may leave your infrastructure, which jurisdictions apply, what your existing data processing agreements permit, whether personal data is involved, and what your sector regulator expects in terms of explainability and audit.

The answers determine whether you can use a hosted API at all, or whether the design needs self-hosted open-weight models — a decision with significant cost and capability implications that is painful to reverse later.

What you receive

A written assessment, not a slide deck of industry statistics. It covers each use case examined with a clear recommendation and the reasoning behind it, a prioritised shortlist with rough effort and monthly running cost, the reference architecture for whatever is recommended first, the risks and constraints that shaped it, and a realistic sequence for delivery including what your team needs to be able to maintain it.

It is written to be usable by whoever is approving the budget, not only by engineers.

How it runs

Framing call — what prompted this, what has already been tried, what constraints exist.
Interviews — the people who would actually use or operate the thing, not only the people sponsoring it.
Data and systems review — where the content lives, what condition it is in, what the integration surface looks like.
Assessment and costing — feasibility, architecture options and running cost at your volumes.
Readout — the written document plus a session to work through it and disagree with it.

Typically two to four weeks depending on scope. Deliberately short: the point is to reach a decision quickly, not to extend the engagement.

Common questions

How long does it take?

Usually two to four weeks depending on how many use cases are in scope and how quickly the right people are available. It is intentionally short — the purpose is to reach a decision, not to build a dependency on the consulting itself.

Do we have to use you for the build afterwards?

No. The assessment is written so another team or vendor can execute it, and it is worth having precisely because it gives you something concrete to evaluate proposals against. If you would like me to build it, that is a separate conversation held after the recommendation, not baked into it.

We already started building. Is it too late?

No, and mid-project is a common point to bring someone in — usually when a pilot works but nobody is confident about production, or when costs are climbing without a clear reason. The review then focuses on what to keep, what to rework and what to stop.

Will you tell us not to do it?

If that is what the evidence supports, yes. Several of these engagements have concluded that the better investment was fixing search, cleaning up data, or changing a process. That is a legitimate and much cheaper outcome than discovering it after two quarters of development.

Can you review a vendor proposal we have received?

Yes, that is a common narrower version of this engagement. It covers whether the proposed architecture fits your constraints, whether the cost model holds at your volumes, what the lock-in looks like, and which questions to put back to the vendor before signing.