Ask a builder to put a second storey on your house and the first thing he does is go and look at the foundation. Not because he does not want the work. Because a wall he puts up on soft ground is his name on the crack.
We turn work down most weeks. Not because it is beneath us, and not because we are precious about it. A short list of honest noes is the only thing that keeps the yeses buildable.
Here is the list. It is short on purpose, and every item on it is a way a build quietly goes wrong.
Work with no finish line
If nobody in the room can say what "done" looks like, the project never ends. It just gets renamed. "Make the process better" is a wish. "The weekly report writes itself by nine on Monday and its owner only checks it" is a finish line. We will help you turn the first into the second. We will not start on the first.
A process nobody has written down
"Just wire the AI into it" assumes there is an it. If the work lives in three people's heads, exceptions and Wednesday workarounds included, there is nothing to build against. Guessing the process and shipping it gives you a system that is right in the ordinary cases and wrong in exactly the ones that cost you. Map it first. Mapping is the cheap part.
A dashboard for numbers nobody trusts
Screens are the easiest thing to sell and the fastest thing to abandon. If the figures are still argued about in meetings, a dashboard only puts the argument on the wall in a nicer font. Settle where the numbers come from first. Then the screen is a small job.
Anything that has to go live before it can be watched
We do not ship a system we cannot see running. If there is no way to tell from the outside whether it did its job this morning, the first person to discover it stopped is your customer, a week late.
A rewrite of something that already works
"While you are in there, could you modernise the rest." An old system is ugly, and it holds knowledge nobody ever wrote down. Replacing it because it is ugly spends your budget to arrive back where you started, minus the quirks that turned out to be load-bearing. Leave it running and build the new thing next to it.
Every no on this list is a promise about the yes: that the work we take on for you actually lands.
Why we say it on the first call
Saying no upfront feels like leaving money on the table. It is not. The work we decline is almost always the work that would have gone sideways, and a team that is not firefighting a doomed project is the team that ships yours on time.
There is a simpler reason too. A clear no is a kind of respect. Walking someone through weeks of discovery you already know will end badly is not kinder than telling them in the first fifteen minutes. It is only more expensive for them.
We try not to say it empty-handed. Usually there is a smaller piece of work that makes the big one possible: write the process down, settle the numbers, name the owner. Do that, and the no becomes a yes.
For the technical reader
Two more refusals sit further down, in the scoping pass rather than the first call.
No named owner on day 30. If nobody will own the result after handover, the system has nothing to attach to and it dies quietly, usually inside a quarter. We screen for that person by name, not by job title.
A step whose correct answer changes weekly. Automating a rule that is still moving means shipping something that is already wrong on the day it lands, then re-shipping it forever. The honest build automates the stable part of the process and routes the moving part to a person with a queue.
Both are checkable before we quote, which makes them gates rather than opinions. Every item above reduces to one test: can we write down, in advance, what has to be true on the day we hand it over? If we cannot write it, we cannot build it, and the useful thing we can do is say so while it is still free.