An AI readiness assessment that ends in working code
An AI readiness assessment answers one question: which AI use cases are worth building in your business right now, and is your data ready for them? Mine runs as a two-week sprint and ends with a scored shortlist, a data-readiness review and a working proof of concept on your real data – or an honest recommendation to wait.
It’s a fixed, bounded piece of work. If it goes well, you can carry on into a build. If it doesn’t, you stop with a clear answer and nothing to unwind.
Who it’s for
A founder, CTO or VP Engineering who has a list of AI ideas, pressure from the board or customers to act, and no evidence yet about which ideas will hold up. You want a decision you can defend, made in weeks, by someone who will look at the data and write code rather than run a maturity survey.
If you already know what to build and need it in production, skip this and go straight to AI integration. If you want ongoing help across several AI initiatives, that’s AI consulting.
What the two weeks cover
- Use-case intake. Short interviews with the people who own the candidate workflows. For each idea: who uses it, how often, what it replaces, and what number would move if it worked.
- Scoring. Each use case scored on value, feasibility, data availability, risk and running cost. Lists usually shrink here, because the value is vague or the data doesn’t exist.
- Data readiness review. For the top candidates: where the data lives, who can access it, how current it is, whether permissions can be enforced, and what sensitive data is involved.
- Proof of concept. The strongest candidate built end to end against a sample of your real data, with a small labeled eval set so its quality is measured, not eyeballed.
- Readout. Results, costs per task at realistic volume, risks, and a recommendation: build, buy, fix the data first, or don’t.
What “data ready” actually means
Most AI readiness frameworks talk about culture and maturity. In practice, readiness comes down to a few concrete checks:
- Accessible: the data can be read programmatically, through an API or database, not just exported by hand from a SaaS admin panel.
- Permissioned: you know who is allowed to see each record, and that can be enforced at query time. This is what sinks most internal assistants.
- Current: there’s a way to know when it changes, so an AI feature isn’t answering from last quarter’s policy.
- Labeled enough to evaluate: you can produce 50 to 200 real examples with known good answers. Without these, nobody can say whether the system works.
- Legally usable: your customer contracts and privacy terms allow it to be processed by a third-party model provider, or the design keeps it in-house.
An AI proof of concept, not a demo
A demo is chosen to impress. An AI proof of concept is chosen to fail fast if it’s going to. So the PoC runs on messy, real inputs, including the awkward cases. It reports accuracy against the labeled set, latency, and cost per call, and it notes what a production version would need – evals in CI, fallbacks, permissions, monitoring. I build it in a way your team can either extend or throw away; the point is the evidence.
Common AI PoC candidates: extracting fields from documents, summarizing and routing tickets, answering questions over internal docs (AI knowledge base), or a narrow agent working one workflow (AI agent development).
The honest no
Some assessments end with “not yet”. The data might be scattered across tools with no API. The use case might save a few minutes a week. The accuracy might top out below what the workflow can tolerate. Knowing that after two weeks is cheap. Finding out after a six-month build isn’t. Everything I recommend is measured on ROI, not demos – the AI ROI guide explains how I do the sums.
Why me
I’ve shipped production software for 20+ years across 200+ projects, so I judge feasibility from what it takes to run something, not from what a demo suggests. At Pepkor NexTech I worked across engineering, architecture and cloud infrastructure while contributing to their AI journey. I also build Craaft, where AI agents and humans share one kanban board through MCP and a REST API.
Questions
What is an AI readiness assessment?
A short, structured review of which AI use cases suit your business, whether your data, systems and policies can support them, and what they would cost to run. A useful one ends with a prioritized shortlist and evidence from a proof of concept, not just a maturity score.
How long does an AI proof of concept take?
A focused AI PoC on one use case can be built and measured within two weeks if the data is accessible. Longer PoCs usually mean the scope is too broad or the data isn’t ready – both useful findings in themselves.
What happens after the assessment?
You decide. You can take the findings to your own team, buy a product the assessment recommended, or carry on with me into a build for a fixed number of days a week. There’s no obligation to continue.
Do you need access to our production data?
I need a representative sample of real data for the proof of concept, under whatever access controls and agreements you require. Where data is sensitive, we can work in your environment or with redacted samples.
Have an AI idea list and no evidence yet?
Send me the list. In two weeks you’ll know which ideas are worth building, whether your data is ready, and how the best one performs on real inputs.
GMT+2 · Full EU overlap · US East mornings