Why we say no to some projects
The six situations in which we decline work, why declining serves the client, and what we suggest instead.
The short answer
We decline projects, not often, and always with the reason. Six situations. The platform requested is one we cannot stand behind for the purpose, such as a page builder for a business site that must be fast, accessible and owned. Another party holds the domain, the hosting or the code and will not put in writing that it transfers to the client on request. The outcome as briefed cannot be delivered, such as a guaranteed ranking or a launch that depends on content that does not exist. The data or the process is not ready for what is asked, typically for automation and AI. The timeline requires skipping the checks that make work safe. Or the fit is wrong: the work needs a specialist we are not, or the relationship would not work. Each no comes with what we would do instead or who else to ask. A supplier who never says no is selling capacity, not outcomes.
The six situations
| Situation | Why we decline | What we suggest instead |
|---|---|---|
| A platform we cannot stand behind | The result would be slow, insecure or unowned, and we would be maintaining it | The stack we build on, with the reasons; or a supplier who specialises in that platform |
| A layer held by another party with no written transfer | It creates a hostage risk we would be part of | Settle the transfer in writing first; we help; then start |
| An outcome that cannot be delivered as briefed | Rankings, sales or dates outside anyone’s control; content or dependencies that do not exist | What can be committed to; a phase that removes the blocker |
| Data or process not ready | Automation on messy data produces confident errors; we would be blamed for the data | The data or process project first; then the automation |
| A timeline that skips the checks | Testing, previews and accessibility are not optional; skipping them ships defects | A smaller scope on the date, or the full scope later |
| Wrong fit | A specialism we do not have, or a working relationship that would not hold | A referral; an honest conversation |
How a no goes
- We say it early, in the first meeting or the proposal, not after weeks of work.
- We give the reason specifically, tied to one of the six.
- We suggest the next step: a different scope, a prerequisite, a different approach, another supplier.
- We leave the door open: many nos become yeses when the prerequisite is met.
- We do not argue past the decision: if the client chooses otherwise, that is theirs, and we wish them well.
What it means for the clients we do work with
Attention. A partner who declines the wrong projects has the capacity to do the right ones properly, and the clients whose work is going well are not competing with a rescue that should never have started. The no is part of the same standard as the monthly report and the preview link: it is what accountability looks like before the contract as well as after it.
What this means for you
If a partner declines your project, ask for the reason and the next step; the answer is often the most valuable advice you receive in the process. If a supplier never declines anything, ask yourself what they would say to a project that could not succeed. A clear no with a reason is a sign of a partner who will tell you the truth once the work starts, which is the quality that matters most.
Frequently asked questions
Is it not the client's decision what to build?
What to build, yes. Whether we are the right party to build it, and whether it can be built as briefed, is ours to say honestly. A client who insists on a platform we know will fail them, or on a timeline that requires skipping testing, deserves to hear that clearly and to hear what we would do instead. Then they decide, with the information.
What do you suggest when you say no?
Whatever fits: a smaller first phase that we can stand behind, a data or ownership task that must come first, a different approach that delivers the outcome, or another supplier who does the thing well. A no without a next step is unhelpful; a no with one is often the most useful conversation of the project.
Does saying no cost you business?
Some, in the short term. It saves more: projects that would have disappointed, clients who would have left unhappy, and the attention those projects would have taken from clients whose work is going well. The businesses that come back after a no, with the data ready or the ownership sorted, are among the best relationships we have.