Enterprise 2–4 weeks Fixed fee Written deliverable

AI readiness assessment:
are you ready to deploy?

Readiness is not about enthusiasm or budget. It is about whether your data is reachable, your processes are describable, and someone can say what a correct output looks like.

WHAT WE ASSESS

Data reachability

Not "do you have data" — everyone does. Can a service authenticate against it, at the granularity needed, with permissions intact, without a six-month integration project? This is the most common blocker and the least commonly anticipated.

Process legibility

Can someone write down how the decision is currently made? Where the rule is genuinely tacit expert judgement, an AI system needs a different design — and a much larger evaluation effort — than where a documented policy exists.

Evaluation capacity

Is there a person who can produce a hundred labelled examples of correct output, and will their judgement be accepted by the people who sign off? Without that, quality is unresolvable.

Governance and constraints

Data residency, approved model providers, audit requirements, works-council or regulatory obligations. These narrow the architecture, so they belong at the start.

Unit economics

What the current process costs per unit, and what an AI system would cost at real volume. Some genuinely good use cases fail here, and it is cheaper to learn that now.

Adoption path

Who changes how they work, and what happens to their day. A technically successful system that nobody adopts is a failed project with good metrics.

HOW IT RUNS

Week 1

Interviews and system access

Sessions with the people who do the work today and the people who own the systems. We ask to see the actual screens and the actual exceptions, not the documented process.
- —Process walkthroughs with practitioners
- —System and data inventory
- —Constraint capture: security, legal, regulatory
Week 2

Data and feasibility probing

Hands-on with a real sample. Frequently this is where a stated assumption meets reality — the field everyone relies on turns out to be free text, or only half-populated.
- —Sample extraction and quality profiling
- —Technical spike on the riskiest assumption
- —Draft evaluation criteria
Weeks 3–4

Written assessment

A document you can circulate internally: what is buildable now, what needs remediation first, what should not be built at all, with cost and effort ranges for each.
- —Prioritised use-case shortlist with effort estimates
- —Reference architecture for the top candidate
- —Evaluation plan and success criteria
- —Explicit list of what we recommend against

QUESTIONS

QUESTIONS — 4

Then it has done its job, and it has done it for a fraction of the cost of finding out during a build. The output in that case is a remediation path: usually data access, evaluation capacity or a process that needs documenting before it can be automated. We would rather write that than take a build engagement we expect to stall.

It helps but is not required. If you arrive with a shortlist we assess those against feasibility and value. If you arrive with “we know we should be doing something”, the assessment includes use-case discovery — which usually surfaces candidates that are less exciting and considerably more valuable than the ones people arrive with.

The deliverable is written to stand alone and to be usable by another vendor. That is deliberate: an assessment whose conclusion is always “hire us” is not an assessment. We are willing to write an assessment recommending an off-the-shelf product, an internal hire, or doing nothing.

Someone who does the work today, someone who owns the systems, and someone who can speak to the constraints — typically security or legal. Three to five people, a few hours each. The most common cause of a weak assessment is only talking to management, because the documented process and the actual process differ in ways only practitioners know.

Keep reading

Enterprise

From Pilot to Production

30-minute technical call · no deck