AI Strategy
The Do Not Build List
Key Takeaways
- •Gartner predicted in 2024 that 30% of generative AI projects would be abandoned after proof of concept by the end of 2025.
- •Gartner cited poor data quality, inadequate risk controls, escalating costs and unclear business value as causes, and the post notes each is knowable before any code is written.
- •MIT's GenAI Divide report found that among organizations evaluating custom enterprise AI tools, 60% evaluated, 20% piloted, and 5% reached production.
- •In Dodge Construction Network's 2025 survey, contractors named output reliability and accuracy as their chief concern at 57%, ahead of cost.
- •The post says an annual rate negotiation prep that happens four times a year at ninety minutes each totals only six hours annually, so it never returns the build cost.
- •The post says a real exclusion is a specific finding with a reason attached, and that it is short.
- •The post says projects that survive an honest screen have a higher hit rate, so the first build works and a second one follows.
I have never seen an AI assessment come back and say no.
Think about how strange that is. A company brings in a consultant, an agency or a vendor to evaluate where AI could help. Weeks pass. A document arrives. It has opportunities in it, ranked, with estimated value attached. Sometimes there is a roadmap. There is always a phase two.
There is never a section that says: we looked at these four processes and three of them should be left alone, and here is why. Not once, in my experience, in an assessment paid for by the company being assessed and produced by someone who would like to do the build.
That absence is not an oversight. It is the business model showing through the paper.
The Failure Rate Has a Selection Problem Inside It
We have plenty of data about AI projects failing and almost none about AI projects that should never have started.
Gartner predicted in 2024 that 30% of generative AI projects would be abandoned after proof of concept by the end of 2025, citing poor data quality, inadequate risk controls, escalating costs and unclear business value. That was a forecast, and it should be read as one. But look at the four causes. Every one of them is knowable before a line of code is written. Data quality is knowable. Risk tolerance is knowable. Unclear business value is not something that emerges in month three, it is something that was unclear in week one and got written down anyway.
MIT's GenAI Divide report found that of organizations evaluating custom enterprise AI tools, 60% evaluated, 20% piloted, and 5% reached production. That funnel is usually presented as a technology problem. Some of it is. But a meaningful share of the drop between evaluation and production is projects that were correctly killed late, after somebody had already been paid, when they could have been correctly killed early for free.
Meanwhile the contractors in Dodge Construction Network's 2025 survey named output reliability and accuracy as their chief concern at 57%, ahead of cost. They are not asking whether AI is impressive. They are asking whether it will be right, and nobody selling to them is structurally motivated to answer that honestly.
An Assessment That Only Says Yes Is a Sales Document
Here is the test I would apply to anyone who hands you an AI opportunity assessment, including me.
Ask what they recommended you not do, and why. If the answer is a list, ask what evidence produced each exclusion. If the answer is that everything looked promising, you are holding a proposal that has been formatted to look like an analysis.
This is the same standard I argued for on the technology side in Your AI Should Tell You What It Doesn't Know: a system that answers every question with equal confidence has told you nothing about which answers to trust, because it has no mechanism for representing the edge of its own knowledge. A consultant with no exclusions has the identical problem. If the method never produces a no, then the yes it produced does not carry information.
The symmetry matters more than it sounds. We are getting reasonably good at demanding calibrated confidence from software. We ask for citations, provenance and gap reporting. Then we accept an unqualified recommendation from a human being with a direct financial interest in the answer, and we do not ask what it is standing on.
What a Real Exclusion Looks Like
A do not build list is not a disclaimer. It is a specific finding with a reason attached, and it is short.
Do not build: automated purchase order matching. The supplier data lives in a system with no API and no scheduled export. Somebody downloads a report weekly and emails it. Fixing that is a data project that has to happen first, and it is worth doing on its own merits before anything is automated on top of it.
Do not build: the customer-facing quote letter. Your two largest customers require a signature from a named person on your side, and the reviewer will rewrite anything a machine produces regardless of quality. The generation is not the constraint. The review is, and automating upstream of a review that will not shrink saves nothing.
Do not build: the annual rate negotiation prep. It happens four times a year. Even at ninety minutes each, that is six hours annually. At any realistic build cost this never returns, and the ninety minutes is the part of the job the person doing it actually enjoys.
Three exclusions like those tell you more about a business than ten opportunities do. They tell you where the data is broken, where the trust boundary sits, and where the frequency math does not close. Every one of them is a real finding that survives being argued with.
Why This Is Worth Money to the Buyer
The obvious objection is that a consultant who says no gets hired less. My experience has been the opposite, and I think there is a reason.
The exclusions are the only part of the document that proves the method exists. Anyone can produce a list of things that would be nice to automate. Producing a defensible reason not to automate something requires having actually looked at the data, talked to the person who does the work, and counted how often it happens. When a client sees three well-argued exclusions, they stop reading the recommendations as a wish list and start reading them as findings, and the conversation changes character in a way no case study achieves.
There is a second effect that shows up later. The projects that survive an honest screen have a much higher hit rate, which means the first build works, which means there is a second one. Two credible builds beat five approved ones that ship into the abandonment statistics above.
The Takeaway
The most useful page in any AI assessment is the one listing what should not be built, and it is the page almost nobody writes, because the person writing the assessment would like to build things.
So make it a requirement. Before you accept a recommendation, ask what got excluded and what evidence excluded it. If nothing did, you are not looking at an analysis, you are looking at a menu, and the fact that everything on it looked appetizing tells you exactly what the chef was optimizing for.
We ask our AI systems to tell us what they do not know. We should ask the same of the people selling us the systems.
Tracy Thayne is the founder of Expona, an AI consulting practice. We find the recurring decisions that bring work into a business and build the preparation in front of them, stopping where judgment starts. Subscribe to the blog (below) for the weekly take on context, AI and the work in front of the decision.
Frequently asked questions
Why do AI assessments never say no?
The post says the absence of exclusions is the business model showing through the paper. Assessments are paid for by the company being assessed and produced by someone who would like to do the build, so they arrive with ranked opportunities, a roadmap and a phase two, but never a section on what to leave alone.
What is a do not build list?
It is a short list of specific findings, each with a reason attached, about what should not be automated. It is not a disclaimer. The post gives examples based on broken data, a review step that will not shrink, and a task that happens too rarely to repay a build.
How can I tell if an AI assessment is really a sales document?
Ask what the author recommended you not do, and why. If the answer is a list, ask what evidence produced each exclusion. If everything looked promising, the post says you are holding a proposal formatted to look like an analysis.
What does the data say about AI project failure?
Gartner predicted that 30% of generative AI projects would be abandoned after proof of concept by the end of 2025. MIT's report found 60% of organizations evaluated custom tools, 20% piloted, and 5% reached production. The post argues many of these failures could have been killed early for free.
Why would a do not build list be worth money to the buyer?
The post says exclusions are the only part of a document that proves the method exists, since they require looking at the data, talking to the person who does the work, and counting how often it happens. Clients then read the recommendations as findings rather than a wish list. Projects that survive an honest screen also have a higher hit rate.
Subscribe
Get notified by email when we publish a new post. No spam, unsubscribe anytime.