The work we said no to

Most of what a studio publishes is about the work it accepted. This note is about the other pile. Saying no is treated almost everywhere as a failure of sales - a lead that did not convert. Inside this studio it is the opposite: the refusal is the product working. A client who hires us is paying for judgment, and judgment that only ever says yes is not judgment, it is a billing engine. The clearest evidence we can offer that our yes means something is the record of what got a no.

A hard problem is not a big one

The first kind of no is the least dramatic. A brief arrives wearing the word AI, and underneath it is a problem an off-the-shelf tool would answer, or an afternoon of configuration. Nothing about that problem is beneath anyone; it is simply not hard in the way that needs us. The distinction we actually apply is not big versus small but deep versus superficial: a hard problem resists the obvious tool because something about the organisation, its data or its cost of failure is unusual, while a superficial one only looks hard because the vocabulary around it is new. Buying deep expertise for a superficial problem is a bad purchase, and the seller is the only person positioned to say so at the moment it matters. So we say it, point at the simpler option, and lose the engagement on purpose.

Conviction upstairs decides the outcome

The second kind of no took longer to learn, because the projects it protects against look wonderful at the start. The team downstairs is eager, the problem is real, the build would be interesting - and senior leadership is not convinced. Not opposed, just not convinced. We turn these down, and the reason is uncomfortable for a builder to accept: the quality of the implementation does not decide the outcome. An AI system changes how work is done, and a change nobody above it is committed to defending gets reversed quietly, meeting by meeting, until the system is running and unused. The best version of that project fails the same way as the worst one. Declining until leadership is committed is not caution; it is the only reading of the evidence we find honest.

The one thing that cannot be consulted around

The third no is the only absolute one. Messy data disqualifies nobody: data that is unstructured, inconsistent and scattered across many tools and databases is what most organisations have, and working with it is routine. The line is elsewhere. When some of the data a system would need is offline - when it exists in someone’s head, or on paper, or nowhere - there is nothing to build on and nothing a consultant can do about it from outside. Every other precondition can be traded against skill or time. This one cannot, because no outside firm can write down what only your people know. The honest response is to hand the work back: do the documentation first, yourselves, and the conversation can restart on real ground.

One rule, written three ways

Put side by side, the three refusals read less like three rules than one: we take work where our judgment changes the outcome, and decline work where it cannot. The buyer-facing version of that test lives elsewhere in this library; this note is the practice behind it, dated and signed so it can be held against us later. It is the first of a series of dated notes from the studio - essays that record what we did and what we declined, left to stand as written.