Why we say no: the honest-no as a service

Honest AI consulting means being paid for a recommendation rather than for a build, and being willing to recommend against the build. We run a ten-day discovery sprint whose most important output is sometimes a single page that says: buy this instead, wait until this changes, or do not do this at all. Clients occasionally find that disappointing in week two. They rarely find it disappointing in month eight. This article sets out the situations where we say no, how we decide, what a no looks like on paper, and why we structure our commercials so that we can afford to say it.

Why a vendor's no is worth paying for

Most AI vendors are paid to build. Every incentive points towards a yes: the discovery is free, so it has to lead to a project; the team is on the bench, so the project has to start; the demo worked, so the risk is downplayed. The client absorbs the cost of an idea that was never going to work, and discovers it after the budget is spent. A vendor whose discovery is priced, fixed in scope and credited against a build only if a build is the right answer has a different incentive: to be right. That is the design of our AI Discovery Sprint, and it is deliberate.

The four answers a discovery sprint can give

When not to use AI: the patterns we see most

The problem is a rule, not a judgement

If a human can write down the decision as a flowchart in an afternoon, a language model adds cost, latency and uncertainty to something a few hundred lines of ordinary code will do exactly. We have replaced planned "AI classifiers" with a lookup table more than once. It is not a smaller project; it is the correct project.

The data does not exist, or cannot be used

A retrieval assistant over documents nobody has digitised, a forecasting model on two seasons of data, a support agent for a process that lives in one person's head. In each case the honest answer is wait, and the useful work is the unglamorous preparation: capture the process, start the logging, digitise the archive. We will scope that work, and it is cheaper than the AI project would have been.

The risk profile does not allow autonomy

Some decisions should not be made by a model at all, and some should only be drafted by a model for a person to confirm. When a client wants full automation of a decision with a regulator behind it, we will build the assistive version and say so. Our stance on policy-gated actions and shadow mode is described in how to build an AI agent that is safe to run unattended.

The value is not measurable

If nobody can say what number would move, we cannot write an evaluation threshold, and a project without one is a demo with a budget. We push for the number in discovery. When it cannot be found, that is itself the finding.

A product already does it

Custom software is the right answer when the capability is your differentiation. When it is not, buying is faster and cheaper, and we would rather spend the budget on the part of your product that is yours. Our decision framework is in build vs buy vs integrate.

How we decide

The discovery sprint has a fixed shape. Days one to three are interviews with the people who do the work today and a look at the actual data, not the description of the data. Days four to seven are a technical spike on the riskiest assumption: can the documents be read, can the retrieval find the answer, can the model follow the policy. Days eight to ten are the write-up: value model, risk register, the recommendation and, if it is a build, the scoped proposal. The spike is what gives us the standing to say no; it is evidence, not opinion.

What a no looks like on paper

A no is not a shrug. It is a document that states the question, what we tested, what we found, the recommendation, and what would change the recommendation. If the answer is buy, it names products and what the integration would take. If the answer is wait, it names the condition and the preparation work with a price. If the answer is do not build, it explains the simpler fix and, where there is one, offers to do it. The client can take the document to another vendor, and some do. That is fine; the document is theirs. We also record what would change our mind, because a no given today is not a no forever: models improve, data accumulates and processes get written down.

Why our commercials let us say no

Sprint Zero is fixed at $3,250 or ₹2,00,000 for ten working days and is credited against the next build if there is one. Because it is paid, we are not subsidising it with a future project, so we do not need the project to happen. Because it is short, the client's exposure is small. Because our builds are fixed price and fixed date, a bad build hurts us as much as the client, which makes us careful about which builds we take on. The full structure is on the pricing page.

A worked example

A hospital network approached us wanting a voice agent to handle every inbound call, including clinical queries. In discovery we listened to recorded calls with the front-desk team and found three groups: appointment booking and rescheduling, directions and timings, and questions that needed a nurse. The first two were routine, high volume and safe to automate in several languages. The third was neither safe nor valuable to automate, and we said so. The recommendation was a narrower build, with clinical questions routed to a person with a summary, and a measured expansion later. The narrower system is described in the multilingual voice agent case study. The scope that was cut in week two would have been the part that failed in month six.

Team and timeline

A discovery sprint is one senior engineer and one product lead from our side for ten working days, and two to four hours a day from a client sponsor and the people who do the work. It ends with a recommendation and, if it is a build, a fixed-price proposal for a ProofRun or Launch 6. If it is buy, wait or do not build, it ends with the document and nothing else. Clients who want ongoing advisory rather than a build engage our AI strategy practice, which is the same team.

Before you start: a checklist

• Write down the number you expect the project to move, and who owns that number
• Ask whether a rule-based fix has been tried, and why it was rejected
• Check that the data exists, is accessible and can legally be used
• Decide which decisions may never be made by a model in your organisation
• Ask any vendor what share of their discoveries ends in a no, and for an example
• Confirm the discovery is priced and scoped, not a free sales step
• Make the people who do the work today available for interviews

Questions clients ask

• Will you say no just to avoid a hard project? No. Hard projects with real value are the ones we want. We say no to projects whose value or feasibility we could not evidence in the spike.
• Can we overrule the recommendation? Yes; it is your business. We will build a scaled-down version with a clear evaluation gate rather than the original scope, and we will document the disagreement.
• Is a no refundable? No, and it should not be. You paid for an evidence-based answer and received one. The credit applies only if a build follows.
• What if another vendor says yes? Ask them for the test they ran. If they have one and it contradicts ours, we would like to see it.

Related reading

Read AI readiness assessment: the ten questions before you build, the difference between a proof of concept and a demo, and what we stand for on the about page. On the discipline of testing the riskiest assumption first, The Lean Startup remains the clearest primary source.

A vendor who cannot say no cannot be trusted when they say yes; we would rather lose a project in week two than a client in month eight.