Are You Actually Ready for AI? The 10-Point Checklist Before You Hire an AI Development Company

Quick Answer: AI readiness is knowing which measurable process you want improved, whether the data to improve it exists and is accessible, and who owns the result when the model is wrong. The checklist is ten yes/no questions across four groups: Problem (a named process with a metric), Data (exists, accessible, clean enough), Process (review owners, a wrong-answer playbook, a workflow home), and Expectations (budget past the demo). Count the yeses: 8-10 means engage vendors for a build, 5-7 means engage for discovery, 0-4 means no vendor can help you yet.

The stakes are the most quoted number in enterprise AI: MIT’s NANDA initiative found 95% of enterprise GenAI pilots delivering zero measurable return, and S&P Global found 42% of enterprises abandoning most of their AI initiatives, scrapping an average 46% of proofs-of-concept. Almost none of those failures were model failures. They were readiness failures, visible before the first vendor call.

The trigger for this article is a confession we hear in first meetings, usually in these exact words: “The board asked what our AI strategy is. I don’t have one. I’m about to call three vendors and I can’t even tell them what problem I want solved, which feels like walking into a car dealership and saying, sell me something.”

That instinct is exactly right, and it deserves to be taken seriously rather than soothed. A buyer who arrives at a dealership with no destination buys whatever’s on the lot, and the AI version of that purchase is how the 95% statistic gets fed. The good news is that readiness isn’t a transformation program; it’s ten questions, most answerable inside two weeks with people you already employ. Here’s the full checklist, what every “no” means, and what to do with the score. We publish it knowing it may cost us some meetings, because a good AI development company will ask you all ten anyway; arriving with answers is what changes the engagement from a sales pitch into a working session.

“We Need AI” Is Not a Brief

Why do nineteen pilots in twenty return nothing? Not because the models are weak; the same models write production code and handle millions of support conversations elsewhere. The NANDA report’s own framing is the “GenAI Divide”: the gap between organizations that wire AI into measured workflows and those that run demos against vague hopes. A project that starts as “we need AI” has no metric to improve, so it ends as a demo that impressed everyone and changed nothing, which is the purgatory we dissected in why your PoC isn’t improving efficiency. The checklist below is the antidote, and its oldest formulation is 135 years old:

“It is a capital mistake to theorize before one has data.”

Arthur Conan Doyle, A Scandal in Bohemia (1891)

The 10 Points, in Four Groups


Problem readiness. 1. Can you name the process and its metric? Not “customer service” but “first-response time on tier-1 tickets, currently 9 hours.” A no here means the project has no definition of success, and no vendor can supply one. 2. Do you know what the status quo costs? Hours, error rates, lost deals: the number that makes ROI computable later. A no means you’ll never be able to prove the project worked, even if it did. 3. Would you notice a 20% improvement? If a fifth less of the problem wouldn’t be felt anywhere, you’ve picked a problem nobody actually has, and the honest move is picking again; our Efficiency Map is the tool for that re-picking.

Data readiness. 4. Does the data exist, digitally? The process you want automated must have left records: tickets, documents, transactions. A no means the first project is data capture, not AI, and that’s a cheaper, better first project than any model. 5. Can it actually be accessed and exported? Existing in a vendor’s SaaS with no export API, or in a system IT guards like a reliquary, is not access. A no here is the most common silent killer: it’s how pilots that worked on a hand-assembled sample die on contact with the real system. 6. Is it clean enough, and does someone own it? Not perfect: labeled, de-duplicated enough to trust, with a named human who can answer “what does this field mean?” A no means budget a data phase before the AI phase, which every honest vendor will tell you and every dishonest one will skip.

Process readiness. 7. Who reviews the AI’s outputs, by name? Early-stage AI output needs a human in the loop, and “the team will check it” means nobody will. A no means errors ship. 8. What happens when it’s wrong? Not if: when. Who gets told, what gets rolled back, what the customer is owed: Air Canada’s chatbot taught the whole industry that a tribunal will hold you liable for your AI’s confident inventions, and a wrong-answer playbook is what makes that a Tuesday instead of a headline. 9. Where in the workflow does it live? A tool people must remember to open in a separate tab is a tool that gets abandoned by week three; the integration point (inside the CRM, the ticket view, the editor) decides adoption more than accuracy does. A no means you’re building a demo, not a feature.

Expectation readiness. 10. Is there budget past the demo? The demo is the glamorous 20%. The unglamorous 80% is integration, evaluation sets, monitoring, security review, and the second version that incorporates what the first one taught you, and it’s where S&P’s 46% of scrapped PoCs went to die: funded to the demo, starved after it. A no means you’re about to buy the cheap half of a project whose value is entirely in the expensive half.

The Readiness Score: What to Fix Before Engaging, and What a Partner Fixes With You


Count the yeses, and be stingy: a “sort of” is a no. 8-10: engage vendors for the build itself; your answers become the brief, and suddenly the three quotes you collect are comparable because they’re pricing the same described thing. 5-7: engage, but for discovery rather than a build, because the missing yeses are almost always in the Data and Process groups, and those are precisely what a competent partner fixes with you: data access audits, review workflows, wrong-answer playbooks, integration mapping. Paying for a build before that discovery is paying build rates for discovery work. 0-4: don’t call anyone yet, kindly. The missing yeses are concentrated in the Problem group, and that group is the one no outsider can answer, because “which process matters to us and what is it costing” is knowledge only your organization holds. Two weeks with question 1 and a spreadsheet will do more for your eventual AI project than any vendor meeting, and it’s free.

Scored 5-7? That’s exactly what a readiness assessment is for.

Techuz runs AI readiness assessments as a fixed, short engagement: we audit the ten points against your actual systems, fix the fixable ones with your team, and hand you a written brief any vendor can quote against, including us.

Book a readiness assessment

Red Flags in Reverse: When the Vendor Doesn’t Ask

Here’s the checklist’s second use, and arguably the sharper one: it audits the vendors. You now know the ten questions a serious partner needs answered before any honest estimate is possible. So watch what happens in the first meeting. A vendor who quotes your project without asking about your data access, your review process, or your success metric isn’t being efficient; they’re selling what’s on the lot, and the thing on the lot is a demo. The pattern has two famous costumes: the glossy pilot that was never going to survive contact with your systems (the demo-to-deployment credibility gap we mapped in healthcare IT, where the stakes made it vivid), and the “AI” that’s quietly humans-behind-a-curtain or brittle rules in a trench coat, the agent-washing problem. Both share one tell: the sales process avoids your specifics, because specifics are where those offerings die. Flip it around and the ten questions become your vendor filter: the partner who asks you most of them unprompted, and is visibly pleased you have answers, is the one who intends to build something that survives month six. A generative AI development company that gets happier as your answers get more specific is showing you its delivery process; one that gets vaguer is showing you its exit.

Why Unready Projects Fail in Predictable Ways


The reason this checklist predicts outcomes is that each missing yes has its own failure signature, recognizable months in advance. No problem metric produces demo theater: a pilot everyone applauds and nobody can defend at budget time, so it joins S&P’s 46%. Inaccessible data produces the pilot that can’t leave the lab: it worked beautifully on the hand-exported sample and died at the integration meeting. No wrong-answer owner produces the incident, on the AI’s schedule rather than yours. And no budget past the demo produces launch-then-decay: no evaluation set to catch quality drift, no monitoring, no version two, which is the slow-motion failure we traced in the half-life of AI agents. None of these is bad luck, and none is fixed by a better model; they’re fixed by the ten questions, asked in the right order, before the dealership visit. Whether the eventual build is a GenAI feature or classical machine learning development, the readiness work is identical, which is exactly why it belongs to you rather than to any particular vendor’s pitch.

Walk into the vendor meetings holding the brief

Ten answered questions turn “sell me something” into “quote me this.” Techuz will run the assessment with you, or quote against the answers you bring, and we’re equally glad either way.

Start a conversation

FAQs

What should I know before hiring an AI development company?

Ten things, in four groups: which process you want improved and its current metric, what the status quo costs, whether you’d notice an improvement; whether the data exists digitally, is accessible, and is clean enough with an owner; who reviews outputs, what happens on wrong answers, and where the tool lives in the workflow; and whether there’s budget past the demo. A good vendor asks all ten anyway; arriving with answers turns the sales pitch into a working session.

Why do most enterprise AI projects fail?

Overwhelmingly for readiness reasons, not model reasons. MIT’s NANDA research found 95% of GenAI pilots delivering zero measurable return, and S&P Global found enterprises scrapping an average of 46% of proofs-of-concept. The signatures are predictable: no success metric produces demo theater, inaccessible data produces pilots that can’t leave the lab, missing review ownership produces incidents, and no post-demo budget produces launch-then-decay.

What does an AI readiness assessment include?

An audit of the ten points against your actual systems rather than your org chart’s hopes: the problem statement and its metric, a hands-on check of data existence, access, and quality, the design of review ownership and a wrong-answer playbook, the workflow integration point, and an honest budget shape for the unglamorous 80% past the demo. The deliverable is a written brief any vendor can quote against, which also makes competing quotes comparable.

How much data do I need to start an AI project?

Less than the folklore says, but it must exist digitally and be accessible. Modern approaches work from hundreds to thousands of examples for many tasks rather than millions, and generative approaches can start from your documents as they are. The disqualifier isn’t volume; it’s data trapped in a system with no export path, or a process that never left records, in which case the right first project is data capture, not AI.

Should my first AI project be a pilot or go straight to production?

A pilot, but a production-shaped one: wired to real data through the real integration point, with a named reviewer, a wrong-answer playbook, and success measured against the metric from question one. The pilots that feed the 95% failure statistic are demo-shaped: run on sample data, outside the workflow, with no metric. The point of a pilot is to de-risk production, and it can only de-risk what it actually touches.

Sources

Ankush Mathur: Ankush Mathur leads technology at Techuz as CTO & Technical Project Manager, where he helps startups and enterprises architect and scale their software. He's spent his career moving from hands-on development to technology leadership, and enjoys writing about engineering practices, AI, and the decisions behind building solid products.