For my first two years of freelancing I said yes to everything. A "quick" change to the checkout flow on a Friday evening. A logo tweak that turned into a rebrand. A client who wanted the whole site in a second language, in the same budget, because "it's just text." I told myself that yes was how you build a reputation.
What it built was a reputation for being cheap and always available, which is a terrible combination. Eventually I worked out that learning how to say no to a client was the skill I was missing, and that it had very little to do with being blunt.
Short version: a good no is specific, it comes with a price or a date attached, and it arrives early. A bad no is vague, late, and apologetic. Everything below is about moving from the second kind to the first.
Why yes is the expensive answer
Every yes has a cost that doesn't show up on the invoice. The checkout change on a Friday evening cost me a weekend and a regression I found on Monday. The unpaid rebrand cost me the slot I had promised to another client, who then waited two extra weeks and noticed.
The trouble is that the cost lands later and on someone else. The client hears yes, feels good, and builds on it. When the real price turns up, a week into the work, you are no longer negotiating a change. You are retracting a promise. That is a much harder conversation than the one you avoided.
I think of it this way now. A client asking for something outside the agreement is not doing anything wrong. They are checking what the project can hold. If I say yes without thinking, I have told them it can hold anything, and they will keep asking until it breaks.
Say no to the request, not the person
Most of my early refusals sounded like rejection because I phrased them as a verdict on the client. "That's out of scope" is true, and it lands like a slammed door.
What works better is naming the request and describing what happens if it goes ahead. Compare these two replies to the same message.
The first: "Sorry, that's not in the contract."
The second: "I can add the second language. It's about three extra days, because the forms and the emails need translating as well as the pages. If we do it now, launch moves from the 14th to the 21st. Want me to quote it separately, or hold it for phase two?"
The second reply is a no to "inside the current price, inside the current date." It is a yes to everything else. The client keeps control of the decision and I keep control of my calendar. Nobody has been told off.
I should admit that this took me an embarrassing number of attempts. My early versions had so many apologies in them that clients read the message as me asking permission to say no. If you apologise three times, the client concludes you aren't sure, and they push. One sentence of regret is plenty. After that, give numbers.
Scripts I reuse
I keep a small file of replies because I'm bad at improvising when a client is on a call and sounds disappointed. None of these are clever. They work because each has an alternative inside it.
When the request is small but off-plan: "I can do that, and it's outside what we agreed, so I'll send a one-line quote before I start. Usually it's a day or less."
When the request would change the launch date: "That's possible, and it moves the date to the 21st. If the 14th matters more, I'd drop the translated emails and keep everything else. Which do you prefer?"
When the request is something I won't do at any price, such as copying a competitor's site pixel for pixel or shipping something I think is unsafe: "I'm not comfortable building that. Here's what I'd build instead to get the same result." I mean the second sentence. A refusal with no replacement leaves the client stuck, and stuck clients go looking for someone more agreeable.
When the client is the problem and not the request: this one deserves its own section.
When the answer is no to the whole project
Sometimes the right call is to decline before any work starts. I used to treat that as failure. Now it's the cheapest filter I have.
The clearest signals show up in the first call. A client who won't say what the budget is, then asks for a fixed price. A client who has already fired two developers and describes both as "just bad." A client who wants a weekly changing scope at a flat monthly number. None of these mean the person is awful. They mean the project has a shape I can't deliver profitably, and I would rather say that on day one than on day thirty.
I wrote about the questions I ask before quoting in my discovery call checklist. Most of the declines I make happen because an answer to one of those questions was missing or wrong. The decline itself is short: "From what you've described, I'm not the right fit, because I can't hit that price at that scope. If the scope shrinks to X, I'd take it."
Notice the pattern again. Reason, then an alternative. Even when I walk away, I leave a door open on terms that make sense for me.
Put the no in writing before you need it
The easiest way to refuse a request is to have already agreed on how requests get handled. That's what a change process is for. In my contracts I now spell out that anything outside the listed deliverables gets a written quote first, and work starts once the client replies with a yes. I covered the clauses I check in my freelance contract template post. With that in place, "I'll send a quote" stops sounding like me being difficult. It is just the process we both signed.
Basecamp's Shape Up book has an idea I borrowed for conversations like this. They describe an appetite: you decide how much time something is worth first, then design to fit it, instead of estimating a design and getting a number out of it. The book puts it plainly: appetites start with a number and end with a design. For a freelancer, that reframes the awkward moment. When a client adds a feature, the honest question is what comes out or how much longer the project runs. You can ask it without sounding like you're refusing anything. Both options are on the table, and the time budget stays fixed unless somebody consciously changes it.
If you want the wider picture of how the project is structured, the Shape Up book is free online and written for product teams, but the scope chapters translate to a one-person shop surprisingly well.
What to try this week
Open your last three client threads and find the places where you said yes in under a minute. Pick one that you now regret. Write the reply you wish you'd sent, with a price or a date in it, and save it to a notes file. That file becomes your script library.
Then, before the next client call, decide your walk-away point: the lowest rate, the latest deadline, the one kind of request you won't take. Write those down where you can see them. Saying no is much easier when the line was drawn before anyone was asking you to cross it. I share more of how I run projects on my portfolio, and the scripts above are the ones I actually paste.
Originally published at abrarqasim.com. I write there about React, PHP, Rust, Go and the AI tooling around them.
Top comments (0)