Notes · 18 Sep 2026 · 6 min read

The week-four decision

Ragu AI is an AI consultancy. We take one workflow past the pilot and into production, inside your cloud and your access controls, with review gates, an audit trail on every answer and a way back.

Four weeks is long enough to know whether an AI initiative deserves a build, and the cheapest point at which to hear no. We put that decision in the contract, on a date, before we start, and we are paid the same whichever way it goes. We do this because the failure mode of AI projects is not that they end badly. It is that they do not end.

Why AI projects do not end

By month three there is a budget line. By month six there is a steering group, a slide in the board pack and a director's reputation attached. Nobody has decided the project is working, but the cost of saying it is not has gone up every week, and the honest answer that would have been cheap in week four is now expensive for everyone in the room. So the project continues, renamed as a phase two, and the question of whether it should exist is never asked again. We have watched this happen from outside more often than we would like, and it is never because the people involved are foolish. It is because nobody built in a moment when no was allowed.

Why four weeks and not eight, or two

Two weeks is long enough to form an opinion and not long enough to test it against the people who do the work. Eight weeks is long enough for attachment to form. Four is the window in which you can sit with leadership, sit with the operators, build a proof on real data and write it up, and still walk away with nobody's pride invested. Week one is leadership: what would this be worth and where does being wrong cost the most. Week two is the people doing the work, sitting beside them, because the gap between what leadership described and what happens on a Tuesday afternoon is nearly always the finding. Week three is the proof, small on purpose, built to be caught being wrong in the ways this business would care about. Week four is the write-up.

"Not yet" is the answer nobody sells

There are three possible answers and the market only sells one of them. Yes is easy; it is what everyone in the room wants to hear and what the consultancy is usually paid to say. No is rare but at least it is clear. Not yet is the most common honest answer and the least commercially convenient, because it means telling a client that the thing they want is a good idea whose prerequisites are not in place, and that the consultancy should not be paid to build it until they are.

In our experience not yet usually means one of three things. The data lives in six places and two people's heads, and no system can be trusted on it until it lives in one. Nobody owns the workflow, so nobody could own the system that changes it. Or the process changes every week and would need to settle before it could be automated, because you cannot review a system against a standard that moves. Each of those is fixable, and each is a better use of the next quarter than a build would have been. The client who hears not yet and fixes the prerequisite comes back and builds something that works. The one who was told yes builds something that does not, and does not find out for a year.

Why a fixed fee is the only structure in which no can be said

This is the part people underestimate. If the assessment is priced by the hour, every extra week is revenue and no is a lost sale. If the assessment is a discount on the build, no is a loss. Only when the assessment costs the same whichever answer it produces is the consultancy actually indifferent, and only an indifferent consultancy can be trusted to tell you to stop. When we say we are paid the same to say no, that is not a boast about our character. It is a description of the incentive, and we would tell you to trust the incentive over the character every time, including ours.

How to make the decision cheap

Put the date in the contract. Fix the fee for the assessment. Ask for a written recommendation, not a presentation, because a document can say no and a presentation almost never does. Insist that the proof ran on your data rather than a demo set. And keep the framework: the ranking of where AI pays in your business and where it does not, on value, feasibility, cost and risk, with the reasoning shown. That framework is the thing clients underrate at the time and use for years afterwards, because it lets them say no to the next vendor without anyone in the room.

What you leave with, whichever answer

Our version is Map + POC: two to four weeks, about $20,000, ending in one of the three answers, in writing. If yes, Build is a fixed fee scoped from what Map found. If not, you keep the ranked list, the evidence from the proof and the sequence of what would have to be true, in order. We count a no as a successful engagement and we mean it, because you paid a known amount to avoid an unknown one. The detail is on our pricing page.

Common questions

Three questions this raises.

How long should an AI proof of concept take?

Two to four weeks, on your data, ending on a date in the contract with a written decision. Longer proofs tend to become projects without anyone deciding they should, because the cost of saying no rises every week.

What does "not yet" usually mean?

One of three things: the data lives in too many places to be trusted, nobody owns the workflow, or the process changes too often to be reviewed against a standard. Each is fixable and each is a better use of the next quarter than a build.

Why does the fee structure matter for an honest answer?

Because a consultancy paid by the hour loses revenue by saying no, and one discounting the assessment against the build loses the build. Only a fixed fee that costs the same either way makes the consultancy indifferent, and only an indifferent consultancy can be trusted to say stop.

If the pilot worked and the business didn’t change, talk to us.

One conversation. A number, a workflow, an honest read. Sometimes the answer is to wait, and we will say so.

Get an honest read