Find out what you can actually build.
A readiness assessment that ends in a decision rather than a maturity score — and that is willing to conclude you should not build the thing you asked about.
A decision, not a scorecard
Most AI readiness assessments produce a scorecard. Your organization rates 2.4 out of 5 on data governance, 3.1 on talent, 2.8 on infrastructure. The scorecard is then filed, and nobody's decision changes as a result of it.
We think that is the wrong artifact. The question a leadership team actually has is not how mature are we — it is what specifically should we do, in what order, and what will it take. A readiness assessment that does not answer that has not finished.
So ours ends in a recommendation: build this, fix that first, buy this rather than building it, and do not do these three things at all. With the reasoning attached, so you can disagree with it on the merits.
What we assess
Is the foundation real?
Not whether you have data — everyone has data. Whether it is accurate, current, accessible, and complete enough to support the level of autonomy you are contemplating. Data quality sets the ceiling on what can be automated safely.
Is it understood and owned?
Who makes the decision today, on what basis, and what happens at the exceptions. A process nobody owns cannot be automated, because there is no one who can define what correct means.
What does being wrong cost?
This sets how much rigor the work deserves and how much autonomy the system should have. It is the single most useful number in the assessment and the one most often left unquantified.
What does it have to touch?
The systems of record, the identity and permission model, the audit requirements, and the human workflow the output lands in. Integration surface is where AI projects quietly go from ten weeks to ten months.
Does the arithmetic work?
Inference cost at real volume, engineering cost to build and maintain, and the value of the outcome. Some genuinely impressive systems should not be built because the unit economics never close.
Will it survive contact?
Sponsorship, the people whose work changes, and who operates the thing after launch. The most common cause of a failed AI deployment is not the model — it is that nobody owned it on day 90.
What you get
Where AI would create real leverage in your operation, ordered by value against difficulty, with the reasoning shown rather than asserted.
Per opportunity: build now, build after a specific prerequisite, solve it without AI, or do not solve it. Named prerequisites, not a maturity band.
For anything we recommend building — the shape of the system, the integration surface, the autonomy level the consequence justifies, and what has to be measured.
Honest ranges, with the assumptions stated. We would rather give you a wide range you can trust than a precise number you cannot.
Why we can afford to tell you no
An assessment is only worth reading if the firm producing it can afford to tell you no. Ours is arranged so that it can.
Qualification is free — the first conversation exists to determine whether there is a case worth pursuing at all. Discovery is paid, because examining your systems, data, and economics is professional work. And for appropriate projects, paid discovery credits toward the implementation engagement.
The rule underneath all of that: we must never be financially punished for telling you not to buy the larger project. That is what makes the recommendation worth something.
Questions we get asked
- ?
What is an AI readiness assessment?
A structured evaluation of whether an organization can successfully deploy AI for a specific set of opportunities. A useful one examines the data foundation, process ownership, consequence of error, integration surface, unit economics, and organizational capacity to operate the result — and ends in a concrete recommendation rather than a maturity score.
- ?
How is this different from the assessments large consultancies run?
Two differences. Ours ends in a decision about specific opportunities rather than a maturity rating, and it is run by people who also build the systems, so the feasibility judgments come from implementation experience rather than from a framework.
- ?
How long does an assessment take?
Typically weeks rather than months, scaled to the number of opportunities in scope. Our doctrine explicitly caps this: discovery must never become billable archaeology. We understand only as much as necessary to make a responsible decision.
- ?
What if the assessment concludes we should not use AI?
Then we say so and explain why. That is a real and reasonably common outcome — conventional software, deterministic automation, or process redesign is frequently the better instrument. You still receive the analysis and the alternative recommendation.
- ?
Do we need this if we already know what we want to build?
Not necessarily. If the opportunity is clear, the process is well understood, and the data is sound, we can go straight to design and build. The assessment exists for the case where the ambition is clear but the path is not.
- ?
Does the assessment cost count toward a build?
For appropriate projects, yes — paid discovery credits toward the implementation engagement. You receive independent value either way, which is what allows us to recommend against building when that is the honest answer.