The AI readiness checklist.
Whether an AI feature is ready to be built comes down to data, workflows, evaluation, guardrails, and cost. This is the list we run before we agree to build one, published in full.
01
Is the problem actually right for AI?
The most expensive AI mistake is building AI where ordinary software would do. These questions filter out most bad projects before any money moves.
- The task involves judgement over messy inputs at a volume humans cannot keep up with. If it is rules over clean data, write the rules instead.
- An occasional wrong answer is survivable, because a review or correction path exists. If one wrong answer is catastrophic, the design must start from that fact.
- The value is measurable: hours saved, cases handled, response time cut. If nobody can say what better looks like, the project cannot succeed or fail, which is worse than failing.
- Someone has checked whether a simpler fix, a form, a filter, a workflow change, gets most of the value for a fraction of the cost.
- There is a real owner who wants this to work, not just a mandate that the company should do something with AI.
02
Is the data ready?
Every AI feature is fed by data from the rest of the business, and the feeding is usually the hard part. Most stalled AI projects stall here, so this section earns its length.
- You can point at where the truth lives: the documents, records, or systems the AI must answer from.
- That source is current, and someone owns keeping it current. An AI answering from last year's policies is a liability with a chat interface.
- Permissions are understood: who may see what, and how the AI will respect that when it answers different people.
- The data is reachable in practice, not locked in scans, screenshots, or a system with no export.
- You have the right to use it this way, including customer data, licensed content, and anything contractual.
- The sensitive data path is decided: what may enter a prompt, what gets logged, and where it all flows.
03
Does it fit the workflow?
An AI feature that does not sit inside how people already work gets admired and then ignored. Adoption is decided here, before any model is chosen.
- You can name the exact step in the existing workflow where the AI acts, and what it produces there.
- You know who acts on the output, and what they do differently because of it.
- The person in the loop saves visible effort. If the AI adds a checking step without removing a bigger one, it will be routed around.
- The escalation path exists: when the AI is unsure or wrong, the case goes somewhere specific.
- Something gets retired. If no manual step disappears, ask honestly where the value comes from.
04
How will you know it works?
Quality that is not measured is quality that is assumed, and assumptions do not survive real users. Evaluation is what separates an AI product from an AI demo.
- A good answer is defined in writing, by the people who own the outcome, in plain words.
- An evaluation set exists or is planned: real inputs with agreed good answers, before launch, not after.
- The hard cases are in it on purpose: the ambiguous input, the trap, the case where refusing is the right answer.
- You care about the floor, not the average. The question is how bad is it at its worst, and can you live with that.
- Someone is named to read the failures regularly, because the pattern in twenty bad answers is worth more than any score.
05
What guards the failures?
The model will be wrong in front of a user. That is a schedule, not a risk. Readiness means the product already knows what happens in that moment.
- There is a confidence threshold below which the system declines rather than guesses.
- The handoff to a human is designed: who receives it, with what context, and how fast.
- The wording distinguishes what the system found from what it thinks, so users can calibrate their trust.
- Answers cite their sources where it matters, so a reviewer can check rather than believe.
- In regulated domains, the audit trail is built in from day one: what was asked, what was answered, and from what.
06
Do the economics survive volume?
Plenty of AI features work beautifully and cost too much to run. Cost and speed are product decisions, and they are cheapest to make before launch.
- The cost per interaction is modelled at real volume, not at demo volume.
- A smaller, cheaper model has been tried for the easy cases, with the large one held for the hard ones.
- Latency is acceptable inside the real workflow, measured where users will feel it.
- Spend is visible and capped, so success does not arrive as a billing surprise.
- Someone owns the system after launch: watching quality, growing the evaluation set, and catching drift before customers do.
Ready, or almost ready?
Bring your answers, especially the uncomfortable ones. We will be straight about whether the idea is ready to build and what to fix first.