Sometimes the Right Answer Is "Do Nothing"

The most valuable advice I gave last quarter cost a client nothing to act on, because the advice was to do nothing. They had budget approved, a board that wanted "an AI strategy," and a shortlist of vendors. What they didn't have was a problem worth solving with AI yet. So I told them to keep their money. Knowing when not to use AI is, oddly, one of the most useful things an honest consultant can offer — and it's the part almost nobody sells you.

This isn't anti-AI. I build these systems for a living. It's a plea for restraint as a first-class engineering decision. "Do nothing" — for now, or on this particular idea — is frequently the highest-return call on the table, and the discipline to make it is rarer than it should be.

The pressure to "do something with AI"

There's a peculiar anxiety in boardrooms right now. Competitors are announcing AI initiatives. Investors ask about your AI roadmap. Someone forwarded a demo that looked like magic. The result is a quiet pressure to launch a project so you can say you have one — and that pressure is precisely how money gets set on fire.

The numbers back up the caution. RAND's study on why AI projects fail found that, by some estimates, more than 80% of AI projects fail — roughly double the failure rate of IT projects that don't involve AI — and the root causes are overwhelmingly organisational, not technical: unclear purpose, weak data, fading sponsorship. A widely-cited 2025 MIT study (the "GenAI Divide" report) found that around 95% of corporate generative-AI pilots delivered no measurable impact on the bottom line. And S&P Global's 2025 survey reported that the share of companies abandoning most of their AI initiatives jumped to roughly 42%, up sharply from the year before.

Read those together and a pattern appears. The problem usually isn't that the technology can't work. It's that the project should never have started in the form it did. Which means the cheapest, fastest improvement available to most organisations is simply not starting the wrong projects.

The signs the right answer is "do nothing" — at least for now

Over enough engagements you start to recognise the tells. None of these mean AI is wrong for you forever. They mean it's wrong right now, in this shape, and that the disciplined move is to wait or to fix something else first.

The process underneath is unclear

If nobody can describe how the work actually happens today — who does what, in what order, with which exceptions — then automating it just encodes the confusion at speed. I've written separately about why most people don't need more software; the same logic applies with extra force to AI. A messy manual process becomes a messy, expensive, hard-to-debug automated one. Fix the process on paper first. Sometimes that fix is the whole win, and the AI was never needed.

The data isn't there yet

Most ambitious AI ideas die on data, not on models. If your records are scattered across spreadsheets, inboxes and three systems that don't talk to each other, no model will save you. The honest sequence is often: do nothing on the AI, and spend the next two quarters on data engineering instead. Unglamorous, but it's the foundation everything else stands on. Building the model first is like installing a turbo on a car with no wheels.

The problem is too small to matter

Some tasks are genuinely annoying but rare. Automating something that happens twice a month, takes ten minutes, and is done by one person who doesn't mind doing it is a classic trap — the build, maintenance and oversight cost dwarfs the saving forever. AI shines on volume and repetition. If the volume isn't there, do nothing and spend the attention where it compounds.

The timing is wrong

This one is underrated. Models are getting cheaper and more capable on a steep curve. A use case that needs a fragile, expensive scaffold of workarounds today may be a clean, cheap, off-the-shelf feature in nine months. If something is technically possible but only just — held together with heroic prompt engineering and a prayer — it's often smarter to wait for the ground to firm up than to ship something you'll rip out next year. Doing nothing now can be the move that lets you do the right thing later, for a fraction of the cost.

The risk or regulation isn't settled

In Europe especially, the governance picture matters. The EU AI Act phases in obligations by risk tier, and some use cases carry duties you don't want to discover after launch. If a proposed system would sit in a high-risk category, or touches personal or sensitive data in ways you haven't worked through, the responsible first step may be to pause and map the obligations — using frameworks like the NIST AI Risk Management Framework — rather than to ship and hope. Doing nothing while you get the governance right is not delay; it's due diligence.

"Do nothing" is not the same as "never"

I want to be precise here, because "do nothing" sounds defeatist and it isn't. It almost never means "AI has no place in your business." It means "not this, not yet, not in this form." It's a timing and sequencing decision, not a verdict on the technology. The best AI roadmaps I've seen are mostly a list of things deliberately not being built this year, so that the one or two things that matter get done properly.

Restraint is what makes the eventual "yes" credible. A team that has said no to five shiny distractions has the focus and the goodwill to do the sixth thing — the one that actually moves the business — really well.

The opportunity cost nobody puts on the slide

Every project you start is a project's worth of attention you can't spend elsewhere. That's the cost that never appears in the business case. When you greenlight an AI build that shouldn't exist, you're not just risking the build budget. You're spending your best people's focus, your change-management capacity, and your organisation's limited appetite for new tools — all on something that, at best, breaks even.

There's a trust cost too. Ship an AI feature that underdelivers and you don't just waste money; you teach your team and your customers that "the AI thing" doesn't work. The next initiative — possibly the one that would have been brilliant — now starts from a deficit of belief. Premature, half-baked automation poisons the well for the good stuff. Doing nothing protects that well.

How we actually decide

When a client brings me an AI idea, I don't start with models or tools. I start with three blunt questions, and if a use case can't survive them, my honest recommendation is to do nothing on it.

• Is this a real, frequent, expensive problem? Not interesting — expensive. If it doesn't cost real money or real hours at real volume, the saving won't justify the build.
• Do we have, or can we cheaply get, the data and the process clarity to do it well? If the answer requires a year of cleanup first, that cleanup — not the AI — is the actual project.

• Is AI genuinely the best tool, or is it the fashionable one? A clear form, a rule, a tidied-up workflow, or an off-the-shelf product is sometimes the better answer. We're vendor-neutral on purpose: the goal is the outcome, not the AI.

This is the same spirit as a proper AI readiness assessment — figure out what's true before you spend. Plenty of times the most valuable output of a first call is "you're not ready, here's the cheaper thing to do instead, talk to us in two quarters." It doesn't bill much. It earns a lot of trust.

What "doing nothing" looks like in practice

"Do nothing about AI" rarely means do nothing at all. It usually means doing something cheaper, more boring, and more useful first.

• Fix the process. Map it, remove the obvious waste, agree who owns the outcome. Often the bottleneck wasn't a missing model at all.
• Buy, don't build. If a mature off-the-shelf product already solves 90% of it, the disciplined choice is usually to buy it. We help clients work through that exact build-vs-buy decision honestly, even when "buy" means we build less.
• Improve the data quietly. Consolidate, clean and connect your records so that when the right use case does arrive, you can move in weeks instead of quarters.
• Wait, on purpose. Put the idea on a "revisit in six months" list with a clear trigger — a price drop, a model capability, a volume threshold — that flips it to "go."

A short story about premature automation

A few years back I watched a company rush to automate a customer-onboarding step because a competitor had announced something similar. The process they automated changed three months later for unrelated business reasons. The clever automation now didn't fit, fought the new workflow, and quietly created more manual cleanup than it ever removed. They eventually switched it off. The lesson wasn't "automation is bad." It was that they'd automated a moving target to look current, instead of waiting for the process to settle. A season of doing nothing would have saved the build and the rip-out.

Who pushes for AI that shouldn't be built

It helps to know where the pressure comes from, because it's rarely the use case itself shouting to be automated. Three sources do most of the pushing. There's board-level fear of missing out — the sense that everyone else is "doing AI" and you'll look asleep at the wheel if you aren't. There's the demo effect: a polished five-minute demo hides the 18 months of messy integration, edge cases and maintenance behind it, and it's intoxicating. And there's the vendor whose business model only works if you build — if the only tool someone sells is a hammer, every problem you describe will turn out to be a nail.

None of these are about your actual operations. A good advisor's job is to filter the pressure back out and ask the quiet question again: what problem, exactly, are we solving, and is AI genuinely the cheapest good way to solve it? We're vendor-neutral precisely so that "don't build" stays an answer we're allowed to give.

When a plain rule beats a model

One of the most freeing things you can internalise is that AI is not automatically more sophisticated than the alternatives. For a lot of tasks it's the worse engineering choice. If a job is deterministic and low-variance — the same inputs should always produce the same output — a simple rule, a lookup table, or a few lines of conventional logic will be cheaper, faster, fully predictable, and trivial to audit. Bolt a language model onto that and you've added cost, latency, and a small but real chance of a confident wrong answer, in exchange for nothing.

AI earns its place where the inputs are messy, varied, and human — unstructured text, images, natural-language questions, judgement calls at scale. The honest test is: would a clear rule handle 90% of cases? If so, write the rule, and consider whether the remaining 10% really needs a model or just a human. Reaching for AI on a problem a spreadsheet formula could solve is a tell that the technology, not the problem, is driving the decision.

Why Dutch SMEs especially should resist the rush

For mid-market and SME companies here in the Netherlands, the case for restraint is even stronger. Teams are leaner, budgets are tighter, and there's no large innovation department to quietly absorb a failed experiment. A six-figure pilot that goes nowhere doesn't just lose the money — it can sour an owner-led business on technology for years. Add the European compliance overlay, where the EU AI Act's obligations land on you regardless of size, and the cost of starting the wrong project is real and personal.

The good news is that the disciplined path also suits how Dutch SMEs like to operate: pragmatic, allergic to hype, sceptical of slideware. Start by getting the process and the data right, buy the boring off-the-shelf thing where it fits, and reserve a real custom build for the one problem where it genuinely pays back. That sequencing is exactly how we work with companies in the Utrecht region and beyond — outcome first, AI only where it earns its keep.

Putting "wait" on the roadmap without looking behind

The hardest part of recommending "do nothing" is political, not technical. Nobody wants to tell a board "we're not doing the AI project this quarter" and look like they're falling behind. So frame it as what it actually is: a sequencing decision with a plan. "We're spending Q3 making our data ready and fixing the onboarding process, which is what any successful AI build would depend on anyway. We'll revisit the model in Q1, when the groundwork is done and the tooling is cheaper." That's not falling behind — it's refusing to skip the foundations. A roadmap that's honest about what it's deliberately not building yet is far more credible than one stuffed with launches that quietly never ship.

When the answer flips to "yes, now"

So when do you actually go? When the problem is real, frequent and costly; when the data and the process are good enough; when AI is the right tool rather than the trendy one; and when the timing and the risk picture make sense. When those line up, you should move with conviction — that's exactly the work we love, and it's why having said no so often makes the yes worth something. The point of all this restraint isn't to avoid AI. It's to make sure that when you do build, you build the right thing, once, properly.

A one-line gut check before you spend

If you want a single test to carry into your next AI conversation, use this: would you spend your own money on this build if the word "AI" were removed from the pitch? Strip the label and describe the project in plain terms — "we want to spend six figures so the system can guess the right answer to a question a rule could answer" rarely survives that translation, while "we want to read ten thousand free-text complaints a month and route them correctly" sails through. If the idea only sounds compelling because it has AI in it, that's your signal to do nothing and look again.

The honest close

If you take one thing from this: a good AI partner should be willing to talk you out of a project. We'd rather tell you to wait and keep your trust than sell you a build that joins the 80% that fail. When something is worth doing, our usual path is an audit from around €2,500 to map the right use case, a proof of concept from around €20,000 to prove it works, and production from €50,000 to scale — usually with a working prototype by the second call. But the first honest question is always whether to build at all. Review our transparent pricing, or book a free consultation and we'll tell you straight — including, if it's the right answer, that the best move is to do nothing yet.

Frequently asked questions