Saying No to a Project
The hardest skill in freelance work is not technical. It is declining work when you have capacity and the money would be useful.
I have got it wrong in both directions — taken projects I should not have, and been slower than I should have been to say so. What follows is what I have learned about which ones to decline, and why it is usually better for the client too. Clear preparation often matters more than reacting late; this resource develops that idea further.
The ones I turn down
When a builder would serve them better. If someone needs a portfolio, an about page and a contact form, and nothing about their situation is unusual, a good template on a platform is the right answer. Building it custom takes their money and leaves them maintaining something they did not need. I say so on the call, and I lose some of those conversations, which is the correct outcome.
When the budget and the expectation do not meet. Not "the budget is small" — small budgets are fine and often produce the best work, because constraints force decisions. The problem is a small budget attached to a large expectation. If we cannot reconcile those in the first conversation, the project will end unhappily regardless of how well I execute it.
When nobody can say what the site is for. If "what is this supposed to do?" has no answer, no amount of design supplies one. The result looks fine and does nothing in particular, and that is a failure I will be associated with.
When there are too many decision-makers and no decider. Three people with equal say and no tie-breaker produces a design assembled from compromises. Worth naming before starting: someone has to be able to say yes. For an independent reference beyond this site, Harvard Business Review is a useful place to compare approaches.
When the timeline is impossible. Not tight — impossible. Agreeing to a date I cannot meet is a way of making the problem worse later while appearing helpful now.
When I would be the wrong person. Genuinely complex applications, large multi-team builds, specialist domains where someone with experience in the field would do better. Referring that work costs me an invoice and buys something more durable.
The ones I take that look risky
Being even-handed, since the list above could read as fussiness.
Small budgets with clear scope. Frequently the most satisfying work.
People who have been burned before. They ask harder questions and are careful about process, both of which make a better project. It requires patience early and it is usually worth it.
Unusual businesses. Something I have not built before is a reason for interest rather than caution, provided I say clearly that it is new to me.
People who disagree with me. A client who pushes back is engaged. The ones to worry about are the ones who agree with everything and then are quietly unhappy.
How to say it
Early and plainly, without a manufactured excuse.
I don't think I'm the right fit for this, and here's why. Then the actual reason, and where possible a direction: a platform that would suit them, a different kind of specialist, a smaller version of the project that would work.
A no with a useful alternative is a service. Half the people I have declined have recommended me to someone else afterwards, which is not the reason to do it and is a reliable consequence.
What does not work: quoting high to make it go away, going quiet, or taking it and hoping. The last is the worst — it wastes months of somebody's time and money before arriving at the same conclusion.
Why this matters to a client
Because you should be watching for it.
Someone who never declines anything has no view about what they are good at. A developer who says yes to everything is either desperate or indifferent, and neither serves you.
So when you are hiring, ask what kind of project they turn down. A specific answer — I don't do large e-commerce, I refer complex applications on — tells you they know their edges. A vague answer that they can do anything tells you the opposite.
And if someone tells you that you do not need them, take that seriously. It is the most expensive sentence a freelancer can say, and it is almost always sincere.
The part that took longest to learn
Saying no early is kind. Saying no late is not.
The projects that ended badly for me almost all had a first conversation in which something felt off and I said nothing, because it was awkward and the work was available. The doubt does not go away; it becomes a difficult conversation in month two with money and time already spent.
Whatever you think in week one, say in week one. That applies to me and it applies to a client who is having second thoughts. It is the same rule from both sides of the table, and it is uncomfortable in exactly the same way.
The short version
- Declining well is harder than any technical part of this work
- I turn down projects a builder would serve better, mismatched budget and expectation, no clear purpose, no decision-maker, and impossible dates
- I take small budgets with clear scope, clients who have been burned, unfamiliar businesses, and people who argue
- Say it early, plainly, with a useful alternative — quoting high or going quiet is worse
- When hiring, ask what someone turns down; a specific answer means they know their edges
- Whatever you think in week one, say in week one — from either side of the table