The Go/No-Go Decision: How Forward Deployed Engineers Decide Whether to Build at All

A go/no-go decision is the gate you run before committing to build an AI system. It asks one binary question — should this project exist? — and it is separate from deciding what the project should contain. Most AI work skips this gate entirely. The engagement opens, the requirement is taken, and the first honest conversation about whether the thing was worth building happens six weeks later, in a room nobody enjoys.

The industry numbers make the case better than I can. Gartner found that half of generative AI pilots are abandoned after proof of concept. RAND, reviewing more than 2,400 enterprise AI initiatives, put the share that fail to deliver their intended business value at roughly 80%. Those are not engineering failures. You cannot debug your way out of a project that should never have been greenlit.

Running the gate is the part of the forward deployed engineer's job that looks least like engineering and does the most for the client.

#What a go/no-go decision actually gates

It helps to be precise about what this decision is not, because two adjacent decisions already have good answers and they are not this one.

It is not prioritisation. Ranking a backlog — which of these eleven problems is worth attention first — is a scoring exercise, and RICE handles it well. Prioritisation assumes the work is worth doing and asks about order.

It is not scoping. Once you have decided to build, the scope contract fixes what is in and out before engineering starts. Scoping assumes the project exists and asks about boundaries.

The go/no-go sits upstream of both. It assumes nothing. It asks whether the problem is real, whether the organisation can absorb the solution, whether the arithmetic works, and whether the thing is safe to deploy — and it accepts "no" as a legitimate output. The full sequence, on a well-run engagement, looks like this:

discovery → root cause → go/no-go → scope → build

Skip the gate and you inherit every decision the client already made before you arrived.

#Start with the problem, not the want

Clients open with a want, not a problem. "We want a GenAI chatbot" is a want. It is a solution that someone has already chosen, presented as a requirement. Underneath it there is usually a functional need — reduce support ticket volume — and underneath that, a root problem: our data is fragmented and unsearchable, so agents take too long and customers are frustrated.

I've written before about why "why" comes before "what" and "how", and I won't re-argue it here. What that post doesn't give you is a way to tell, in the room, whether the thing a client is describing is load-bearing or decorative. My mentor Milind Naik has a test for it, and it's the most useful thing I picked up from a recent session on strategic consulting.

He asked twenty of us why we use Uber or Ola instead of hailing a cab on the street. We had good answers. Safety. Driver accountability. Price transparency. Ratings. A choice of vehicle. A company to complain to. He rejected almost all of it with the same question, over and over: is that the ice cream, or the cherry on top of the ice cream?

What survived was three things. Will I get a ride. What will it cost. When will I arrive.

Everything else was real, and mattered, and would not by itself have made anyone install the app. The exercise ran again with food delivery and collapsed just as fast — hungry, choice, convenience, and a long tail of toppings we'd mistaken for the product.

This is the Kano model in plain language: must-be quality versus attractive quality. Must-be features cause severe dissatisfaction when absent but generate no enthusiasm when present. Delighters do the reverse. The trap for an engineer is that delighters are far more fun to describe in a meeting, so a requirements list drifts toward them naturally — and a project justified on toppings will not survive its first budget review.

The question to carry into a discovery room is blunt. If we shipped only this, would the problem be solved? If the answer is no, you are looking at a cherry.

#The four pillars of AI readiness

A real problem is necessary and not sufficient. The second half of the gate asks whether this organisation can actually absorb a solution, and it has four dimensions worth scoring separately.

A note to avoid confusion: these are the four pillars of AI readiness, which are a different set from the four pillars of the FDE role — client interface, product ownership, engineering depth, feedback loop — that I described in an earlier post. Same phrase, different framework.

Strategy and vision. Why is this being done, and what changes if it works? A real answer is tangible: cut operational cost 30%, cut resolution time by half. If nobody can state the target, there is no way to know later whether you succeeded, and the project will be judged on vibes.

Data and infrastructure. No clean data, no project. This is the pillar engineers assess most confidently and clients understate most consistently. Where does the data live, who governs it, is it normalised, is there a backup and a disaster-recovery story, can it legally be used for this, and does the infrastructure exist to serve a model at the volume you're promising?

Talent and culture. Can the organisation run this after you leave? Two human forces decide it, and neither is technical: what is in this for me, and am I about to be automated out of a job. Nobody who believes the second one will help you succeed. Leadership commitment has to be genuine, because a 30% ROI improvement means nothing to the person actually being asked to change how they work.

Ethics and governance. Fairness, explainability, privacy regime — GDPR, India's DPDP Act, the EU AI Act — and a named human who is accountable when the system is wrong. More on this below, because it is the pillar that can override everything else.

Score them honestly, and the weakest pillar is your answer. A project with a compelling business case and no data governance is not a go; it is a data governance project wearing an AI costume.

#The arithmetic the client will ask for

Clients ask for ROI, and they deserve a real number rather than a gesture. The base calculation is unglamorous — net benefit minus total investment, divided by total investment, over a stated horizon, usually twelve months. Alongside it sit payback period (when does this stop costing money), and for larger commitments net present value and internal rate of return, because a rupee saved in year three is not a rupee saved today.

What engineers routinely underestimate is the cost side, and generative AI has more of it than a traditional build:

• Token and inference cost, which scales with success rather than staying fixed — the better the adoption, the larger the bill
• Infrastructure and licensing, ongoing rather than one-time
• The people cost of keeping it correct — evaluation, monitoring, retraining as the model drifts, someone owning hallucinations
• Change management, which Milind puts at roughly three times the technology cost

I'd treat that last multiplier as a practitioner's rule of thumb rather than a measured figure — I haven't found a study that pins it precisely, and the number will vary enormously by organisation. But the direction is right, and it is the line item most often left off the slide entirely. Training, incentive redesign, process rewrites, and the slow work of getting people to trust the output cost more than the model does.

Run the numbers three ways — conservative, likely, optimistic — and present the conservative one first. If the project only clears the bar under the optimistic case, you have found a no-go and given the client the courtesy of learning it before the spend.

This is also where a lot of AI projects quietly become non-AI projects. If the honest comparison shows a scheduled query, a dashboard, or a rules engine hitting the same target at a fraction of the cost, that is the recommendation. I've written a fuller version of that argument in when to use an LLM.

#Where governance overrides the arithmetic

Some no-gos are not financial, and this is the part most engineers get wrong about how senior stakeholders think.

Milind put a case to us. Suppose you've built a deep learning model that ingests patient data and returns a diagnosis — a specific, serious one, requiring surgery. It is accurate. It compresses fifteen days of work into half an hour. And it cannot explain how it reached the conclusion.

Deploy it?

The room said no immediately, and then he asked the harder version: what if the ROI is enormous? The answer doesn't change. An unexplainable model in a consequential decision is a no-go on grounds that have nothing to do with the business case, and no return justifies it.

His observation about boardrooms follows from the same logic, and it inverts what most engineers assume. Governance and ethics, he reckons, occupy something like 70% of a board's attention on an AI initiative — far more than ROI — for a straightforward reason. A missed return target is a bad quarter. A data breach, a discriminatory model, or a regulator's finding is a career and a headline. When you pitch to that room, the risk frame is not a footnote after the value story; for them it is the story.

Practically, this means deciding the accountability model before you build, not after: human in the loop (a person approves each decision), human on the loop (a person supervises and can intervene), or human in command (a person sets the boundaries the system operates within). If a system's consequences demand the first and your design assumes the third, that gap is a no-go until it's closed.

#The no-go that wins the account

Here is the part that feels wrong until you've watched it work.

Someone in the cohort described a live engagement: a client wanted a ticketing bot routing support requests into Jira. He'd worked the problem through readiness and cost, and reached an uncomfortable answer — four people could do this job, and the automation would cost more than they would. He asked whether an FDE is allowed to recommend that.

Milind's answer was that you not only can, you should, and the reason is not integrity for its own sake. Clients evaluate you on two axes: trust — I believe that what he says is true — and confidence — I believe he will deliver what he says. Recommending against your own build is one of the few moves that raises both at once. Sometimes you leave the small fish. The client who hears you don't need this is the client who brings you the larger problem next quarter, because you are now the person whose recommendations can be believed.

The failure mode this guards against is the one Milind named as the default engineering posture: I have a solution, let me go find a problem. Everyone currently holding an agent framework is at some risk of it. The discipline is to find the highest-value problem first and let the architecture follow — and to accept that sometimes the highest-value finding is that there isn't one worth your fee.

DRAFT NOTE — REMOVE BEFORE PUBLISHING. Hemanth's first-person story goes here: a time you told a client, PM or stakeholder that what they asked for wasn't worth building, or that a cheaper non-AI fix was better. Without it this section rests entirely on someone else's example.

#This is hygiene, not paperwork

The most common objection to all of this — raised in the session, and fair — is that it looks like enterprise consulting overhead. If an engagement is two months, who has time for a readiness assessment and an NPV model?

Milind's answer was the best line of the session. This is hygiene. When you start a car, you check that it has fuel, that the battery works, that the brakes respond. You do not run that check because the drive is long. You run it because you are driving. Nobody drives five kilometres without brakes on the grounds that it's only five kilometres.

The depth scales with the stakes — a small internal tool does not need a sensitivity analysis. But the questions don't change. Is the problem real, can they absorb it, does the arithmetic work, is it safe to run? Whether that takes an afternoon or three weeks is a matter of scale, not of whether it applies.

#Stop asking how

The session closed on a reframe I keep returning to.

Suppose I tell you to be at Connaught Place in Delhi at 10am on Saturday. You will immediately start solving for how — train or flight, what it costs, when to leave. Now suppose I tell you why: you have an audience with the Prime Minister.

Nothing about the logistics changed, and every decision just resolved itself. You fly. You arrive Friday night, not Saturday morning, because you will not risk a delay. You buy something to wear. The why dictated the how completely, and you would have got the how wrong without it.

Most engineers, given an AI project, start at how — which model, which framework, which vector store. The go/no-go gate is the discipline of staying on why are we doing this and what has to be true for it to work long enough that the how becomes obvious, or that the project is honestly called off before anyone builds it.

A no-go, delivered early with the arithmetic behind it, is not a lost engagement. It is the cheapest deliverable you will ever hand a client.