I turn down more AI projects than I take on, and it is almost never about budget. AI readiness has nothing to do with the model, and everything to do with whether the business asking for it can actually answer three questions before we start.
What Does "Not Ready for AI" Actually Mean?
It does not mean small, poor, or behind on technology. Some of the best projects I have shipped came from a five-person business with a spreadsheet and a lot of clarity about what was broken. "Not ready" means something narrower and more specific: nobody in the room can name the one task this is supposed to change, the data it depends on is somewhere nobody can currently point to, or the person asking for it will not still be in the building in six months to make sure it sticks. None of those are technology problems. All three show up in the first conversation, long before anyone opens a laptop.
I used to think readiness was a spectrum you worked your way along — a bit of data cleanup here, a bit of process documentation there, and eventually a company crossed some invisible line into being AI-ready. I do not think that anymore. Readiness is not a maturity score. It is a much smaller, much more binary question: can you point at the specific thing that is broken, or are you pointing at a category?
Why I Don't Just Say Yes and Fix the Gaps Later
The tempting answer is to take the project anyway and build the missing pieces along the way — figure out the task while scoping the pilot, find the data while building the pipeline, identify the owner once the demo looks good enough to get someone excited. I did this constantly in the first two years of running this company, and it is the single most expensive mistake I made, repeatedly, before I learned to stop.
RAND's research into AI project failure is the most rigorous version of a pattern I recognised immediately: RAND puts the failure rate above 80%, roughly double the rate for ordinary IT projects, and of the root causes their interviews with data scientists and engineers turned up, the technical ones were the smallest category. Leadership-driven failure — the project chasing a vague ambition instead of a named problem, with no one senior enough actually accountable for the outcome — was the one their industry interviewees named most. That matches almost exactly what I see before a project even starts: the gap was never going to be closed by better code. It was there in the kickoff call, in the fact that the person describing the "vision" for AI in their company could not describe the Tuesday it was meant to change.
Fixing the gap after the contract is signed does not work for a structural reason: once money has changed hands, the incentive to be honest about what is missing gets weaker, not stronger. Nobody wants to be the person who admits three weeks in that the data everyone assumed existed is actually scattered across four people's inboxes. It is far cheaper, for everyone, to have that conversation before anyone has paid for anything.
Why Is It Easier to Say This in the Netherlands Than It Sounds?
I say "this isn't ready yet" to a prospective client more often than most consultancies would admit to, and I have come to think that doing this bluntly is one of the more Dutch things about how I run this business. Erin Meyer's Culture Map plots the Netherlands at the most direct end of the world's negative-feedback scale, alongside Israel and Russia, and separately at the extreme low-context end of the communicating scale, where, as she puts it, if you don't say something straight, people don't trust that you mean it. Two different dimensions in her framework, pointing the same direction: this is not a stereotype I am reaching for to decorate a paragraph, it is a genuinely useful description of what a first call with me sounds like. I am not being tactful when I say a project is not ready. I am doing the thing that, in this culture, actually signals I am worth trusting with the next one.
This matters practically, not just culturally. In markets with a higher-context communication style, a consultant who is not ready to take your project might soften that into something that sounds like a yes with conditions — and the client walks away thinking they have a green light. In a business culture built on saying the blunt thing early, "not yet" is a complete sentence, and everyone in the room knows exactly what to do next. That is not always comfortable. It is, in my experience, considerably faster than the alternative.
It also changes what a "no" costs, reputationally, in a way I think outsiders underestimate about how business gets done here. A client I turn away with a clear, specific reason tends to come back once that reason is fixed, and tends to send someone else in the meantime — because being told the truth, plainly, reads as competence rather than rejection. I would not assume the same holds in every market. In this one, the flat "not yet, and here is exactly why" has generated more referrals for me than any pitch ever has, which is the part of Dutch directness that does not make it into the culture-guide chapter but matters more to a small consultancy than almost anything else.
Why Did This Get Harder in 2026, Not Easier?
You would expect the readiness conversation to have gotten simpler as AI tooling matured, and in one sense it has: nobody needs convincing anymore that the technology works. What actually happened is stranger. Because building a working prototype now takes an afternoon instead of a quarter, I increasingly meet prospective clients who have already built something themselves — a chatbot wired up over a weekend, an agent framework pointed at a spreadsheet, a demo that genuinely does something impressive. That used to be a rare and encouraging sign. In 2026 it is common enough that it stopped being a useful signal on its own, and occasionally it actively gets in the way.
The reason is that a self-built demo answers a different question than the one I am actually asking. It proves the founder or a curious employee can get a model to produce plausible output on a good day with clean example data. It says nothing about whether the underlying task is named precisely enough to build against, whether the real data behind it is visible and current rather than hand-picked for the demo, or whether anyone with the authority to make the new way the only way is actually in the room. A weekend project can pass every test that matters to a hobbyist and fail all three of mine, and the two people in that conversation are often surprised by how little the demo changes my answer.
I do not say this to talk down the tinkering — if anything, I would rather a prospective client had tried something and hit a wall than arrived with only a slide. But the honest version of "we already built a demo" is closer to "we are curious and capable," which is a genuinely good sign about the people, and a separate question entirely from whether this specific project, on this specific data, with this specific owner, is ready to become real work. Conflating the two is the newest way I watch smart people talk themselves past a gap that a cheaper, faster demo made easier than ever to paper over.
What Do I Actually Check Before Saying Yes?
I have written elsewhere about the specific red flags I listen for in the first half hour of a call — an unclear decision, data nobody owns, no real mandate — so I will not re-derive that list here. The short version: a named task, data I can currently see rather than merely hear described, and one person who loses something if this fails. Two out of three is a maybe. One out of three is a "call me again in six months," said as directly as I can manage, because a vague "let's keep talking" wastes both of our time more than a clear no does.
What that earlier piece does not cover, and what I actually want to get into here, is what happens once one of those three is missing and I have to say something out loud in the room.
What Do I Actually Say When the Answer Is No?
Not "let's circle back," and not "send me a proposal and we'll see." Those are the sentences that let both people leave the call thinking something different happened. What I say, as close to word for word as I can manage, is some version of: "I don't think we're ready to start this — here's the specific thing missing, and here's what would need to be true for me to say yes." Then I stop talking, because the instinct in that silence is to soften it, and softening it is exactly what turns a useful no into a confusing maybe.
The specificity is the entire point. "You're not ready for AI" is an insult dressed up as feedback, and nobody can act on it. "Nobody in this room can tell me which invoice step this replaces" is a fact, and it hands the other person something to go and fix, or argue with, or bring back next quarter with a different answer. I try to name the exact one of the three questions that came up empty, say it plainly, and then stop selling — the sale, if there is one, happens later, once the gap is closed by them, not by me smoothing it over now.
The mistake I made for years was treating the no as the end of the relationship instead of the actual first useful thing I did for it. A specific, well-argued no, delivered without hedging, is the clearest signal of competence I have to offer someone in a first call — clearer, usually, than anything I could say about our track record.
What Happens When I Say Yes Anyway
I have broken my own rule enough times to know exactly what it costs. The project that sticks in my memory most is not a disaster — the technology worked fine, the demo was genuinely good, everyone in the room nodded. It just never became anyone's actual job to keep using it, because nobody had lost anything when it quietly stopped being used, and I had known that going in and taken the project anyway because the conversation felt promising and I wanted the work. That is the honest version of why I broke the rule: not naivety, but the ordinary pull of wanting a yes to be a yes. The fix was never a better handover document. It was that I should have said, in the first call, that we were not ready to start.
The pattern repeats with enough consistency that I now treat my own reluctance to say no as the actual risk, not the client's readiness. If I am tempted to talk myself past a missing answer to one of the three questions because the relationship feels good or the sector is exciting, that is exactly the moment to slow down, not speed up.
A "Not Yet" Is Not a "No"
None of this means I think most businesses that come to me are unready — most, eventually, are exactly ready, and a fair number are ready the day they call. What I am describing is a filter, not a verdict, and the honest next step after a "not yet" is almost always small and specific: name the one task, find who currently owns the pain, go look at where the data actually lives today. That is closer to a week of work than a strategy offsite, and it is the same groundwork our readiness scan is built to shortcut — a structured way to answer those three questions before either of us commits to more.
If you already know the answers — the task, the data, the person who will notice if it stops — the conversation moves fast from there, and that is the conversation we actually want to have. We lay out what a realistic engagement costs on our page on what an AI project actually costs, and if you are earlier than that and still working out whether this is the right moment, that earlier conversation — the one that might end in "not yet" — is the one we have first, before any proposal, at Crux Digits.
I have written before about the signals I read in the first half hour of a call and about why I keep those calls under thirty minutes — both are really describing the same filter from different angles. This piece is the part I had not written yet: what happens on the other side of that filter, and why turning a project down is, more often than it should feel, the most useful thing I do for someone that week. Readiness is not a compliment or an insult. It is closer to a diagnosis, and like most honest diagnoses, it is far more useful the earlier you get it.
