What we turn down, and why

An agency with no refusal rules will build whatever you ask for, which sounds like service and is the single most reliable way to end up with a system nobody can defend. These are the six requests we decline, the reasoning in each case, and what we propose instead. Most of them are declines that cost us the larger engagement, which is the only reason the list is worth anything.

Ask any supplier what they refuse to build. The answer, or the absence of one, is more informative than the case studies.

Key takeaways

A refusal list is only credible if the items on it are commercially expensive. Ours are.
Four of the six are declined on evidence: no baseline, no owner, no data, no agreed process.
Two are declined on principle, and would stay declined at any price.
Every decline comes with the smaller thing we would do instead, because a refusal without an alternative is just a lost meeting.
Use these as tests on whoever you are considering, including us.

Who this applies to

You are choosing a supplier, or you are one. The commercial framing of the same subject is how to evaluate an AI agency proposal, which is about reading what you are sent. This is the other side of the table, written down so it can be checked.

The six

1. A build with no way to tell whether it worked

If nobody can say what number this is supposed to move, or what that number is today, we will not start the build.

This is the most frequent decline and the least popular. The system will get built, it will produce output, and in six months there will be no way to establish whether it helped, which means no way to defend the spend and no way to justify the next phase. The whole argument is in we shipped without an eval set.

Instead: a short measurement engagement first. Establish the baseline, then decide what to build. It is a smaller invoice and it makes the second one arguable.

2. A system with no named owner after launch

If the answer to “who runs this in six months” is a shrug, or a team rather than a person, we say no.

An AI system is not a deliverable, it is a thing that needs someone to edit content, approve threshold changes, respond to alerts and read the escalation queue. Without a name, the system decays quietly and the failure lands on whoever is nearest a year later. The roles are set out in what an AI roadmap should actually contain.

Instead: we scope the version a real person can own, which is usually narrower, or we help make the case for the role first.

3. Automating a process nobody has agreed on

If three people describe the process differently, automation does not resolve that. It picks one of them and enforces it at speed, and the disagreement resurfaces as a system defect.

Instead: map the process, write it down, get the three people to sign the same page. Then automate. This is often a week, and it is a week that would otherwise be spent arguing about a build.

4. A knowledge assistant over knowledge that is not written down

If the answers live in people’s heads, retrieval has nothing to retrieve, and the model will answer anyway from general knowledge. Confident, plausible, wrong, at scale. This one we decline firmly because the failure lands on customers.

Instead: the documentation project, which is the cheaper half and delivers value with or without an assistant afterwards. The mechanics of what goes wrong are in why retrieval misses the answer that is there.

5. Anything that pretends to be a person

A system that claims to be human when asked, invents a name to build rapport, or is deliberately designed so customers cannot tell. This is a principle rather than a judgement call, and it does not move on budget.

The commercial argument is on the same side anyway: the customers who find out are the ones who were paying enough attention to matter, and they tell people. But we would decline it if the commercial argument pointed the other way.

Instead: disclosure in the first message, which costs nothing and removes the thing people are otherwise testing for.

6. Deceptive or manufactured content

Fake reviews, fabricated case studies, invented statistics, synthetic testimonials, or volume content designed to appear independent. Also declined on principle.

We are strict about this on our own site, which is why there are no client logos and no outcome figures on it. We have not published case studies because we do not yet have client-approved numbers to publish, and inventing them is not an option that exists. That is a visible commercial cost of the rule, on our own home page, and it is the most honest evidence we can offer that the rule is real.

Instead: publish the method rather than the outcome. It is what this entire corpus is, and it is why the first article built on our own measurement is a visibility baseline rather than a client result.

The distinction matters when you are on the other side of it. Ask a supplier which of their refusals are evidence and which are principle, because only one kind is negotiable.

What a good refusal looks like

Three properties, and they are worth applying to anyone.

It is specific. “We only take projects that are a good fit” is not a refusal. “We do not start a build without a baseline number” is.

It has a cost. A refusal that loses nothing is a preference. Ask a supplier for one that cost them a deal, and listen for whether the story has a real shape.

It comes with an alternative. Turning down work and leaving the client where they were is not integrity, it is inconvenience. Every item above has a smaller thing attached.

The second test does most of the work. Specificity can be drafted; a lost deal has details that are hard to invent on the spot.

The one we get wrong most often

We are inconsistent about the volume threshold.

Below a few hundred support contacts a month, or a handful of runs a week for an automation, the honest answer is usually to do nothing yet, and we do say it. But we have taken on work just above that line where the arithmetic was thin, because the client was persuasive about growth that had not happened yet. Twice that growth did not arrive, and the client owned a system that could not repay its own maintenance.

The rule we now try to hold: size the case on the volume that exists, not on the plan. If the case only works at three times today’s volume, the honest recommendation is to wait, and to spend the money on getting to three times.

Every agency site claims integrity. This is the version of that claim that can be checked, by looking at what is missing from the page you are on.

When to ignore a refusal list

When it is generic. A list this shape is easy to write and costs nothing unless the items are real. Test them with your own situation and see whether the answer changes.

When your circumstances genuinely differ. Every rule here has conditions. A regulated buyer with a compliance deadline has different constraints from a founder with a hunch, and the same advice does not fit both.

When it is being used to avoid work. Refusals can be laziness wearing principle. The test is whether the alternative offered is real, specific and smaller, or whether the conversation simply ends.

Frequently asked questions

Do you turn down much work?

Enough that it is a real category rather than a marketing position, and the most common decline by far is the first one on the list. Most of those conversations end with a measurement engagement instead of a build, and some end with nothing.

What if we insist?

For the four evidence-based items we will state the concern once, in writing, and then build what you have decided, because it is your business and you may know things we do not. For the two principles, we will not, at any price.

Is this not just an argument for smaller projects?

It is an argument for projects that can be defended afterwards. Several of them get larger later, because a system with a baseline and an owner is one you can justify extending.

How do we use this list on another supplier?

Ask what they refuse to build, then ask for an example that cost them money. The specificity of the second answer tells you whether the first was real.

Would you publish a project that failed?

We would, with the client’s agreement, and we do not have one to publish yet. Until then the honest position is that the absence of case studies on this site is a fact about our stage, not a claim about our record.

Next step

If you want a supplier to tell you when not to build something, that is a reasonable thing to test before you engage one. AI consulting and strategy starts with the question of whether the thing should exist, and sometimes ends there.