How to Handle Out-of-Scope Client Requests on A Fixed Website Project
A carefully curated Guide To Maintain Freelancers Projects Scope And Maintain Good Client Relationship
It usually starts small. Halfway through a fixed-price website, your client emails: "Could we also add a blog? And can the homepage hero look more like this other site?"
You don't want to sound difficult. You also know the quote didn't include a blog, and the hero is already approved. So you say "sure," and a few evenings disappear.
To handle an out-of-scope client request, compare it with your written scope, decide which of five outcomes applies (included, needs clarification, trade-off, extra work, or deferred), and reply in writing before you do any work. The rest of this article shows how, with examples and replies you can adapt.
Why out-of-scope requests happen on website projects
Most clients aren't trying to get free work. Three things usually cause it:
Clients can't see the whole site until it exists. Once pages are live on a staging link, new ideas appear.
"Small" requests hide real work. A new section can touch navigation, mobile layouts, and other pages. Local Propeller points out that a "simple" late change can turn out to be a mountain of work affecting many other elements.
The scope was vague. If the agreement says "build a 5-page website," nobody has agreed on what counts as a page, a revision, or a feature.
Freelancers contribute too. Saying yes to avoid awkwardness trains clients to expect it. Payoneer's freelancer guide advises acting the first time a client asks for more than was agreed, not after it has become routine.
Step 1: Make your scope specific enough to compare against
You can't judge a request against a fuzzy scope. Before the project starts, write down:
The pages and templates included (name them)
The features and integrations included (forms, booking, e-commerce, blog)
The number of revision rounds, and what counts as a "round"
What the client provides (copy, images, logos) and by when
What is excluded or priced separately (extra pages, new functionality, content writing, ongoing maintenance)
Payoneer warns against vague line items like "Create site." Itemizing lets you say, calmly, "That isn't on the list we agreed."
Step 2: Capture the request in writing, in the client's words
When a request arrives by call, DM, or a comment on a design, write it down in one place before you react. Record:
What the client asked for, in their words
The date and how it arrived
Which page or feature it touches
Wix Studio's guidance on scope creep recommends keeping a central library of change requests and their status. Even a simple table beats scattered messages, because you can't compare what you can't find.
Step 3: Ask why before you decide
A request is often a solution the client has imagined, not the real problem. SureFeedback suggests politely asking what problem the change is meant to solve, because what clients want to accomplish and what they ask to change don't always line up.
Try: "Can you tell me what you're hoping this will do for visitors? I want to make sure we solve the right thing."
Sometimes the answer shrinks the request. Sometimes it shows the request is bigger than it sounded. Either way, you now decide with better information.
Step 4: Sort the request into one of five outcomes
Compare the request with your written scope, then pick one.
1. Included
It's already in the agreement, or it's a normal refinement within your revision rounds. Do it and log it.
Example: The contact form should also email a second address, and your scope says "contact form with email notification."
2. Needs clarification
You can't tell whether it's in scope because the request or the agreement is unclear. Ask one or two specific questions before deciding.
Example: "Make the site more interactive." That could mean a hover effect or a custom calculator.
3. Trade-off
The client wants something new, but the budget and timeline stay fixed. Offer to swap it for something of similar effort.
Example: They want an extra service page. You offer to include it if the planned testimonials slider is dropped.
4. Extra work
It's outside the scope and adds real time or cost. Price it, get written approval, then do it.
Example: Adding a members-only area when the agreement covered a static brochure site.
5. Defer
It's a good idea, but not for this launch. Park it for a later phase so it doesn't derail delivery. SureFeedback suggests reminding clients that there's always a version 1.1 or version 2.
The clarification and trade-off outcomes matter because they stop you from treating every request as a yes-or-no fight.
Step 5: Estimate the impact before you reply
Before answering, estimate three things:
Time: hours for design, development, testing, and client review
Cost: your rate times the time, plus any paid plugin, font, or licence
Delivery: what it does to the launch date and to any other work waiting behind it
If you're unsure, say you'll confirm the estimate by a specific day. A measured answer is more professional than a rushed yes or an improvised price.
Freelancers in a Treehouse community thread describe being generous with tiny changes while billing hourly for added features or design work, with contract language that prepares the client for it. That approach works when you decide in advance where "tiny" ends.
Step 6: Reply professionally, with an option attached
Good replies acknowledge the idea, state the scope fact plainly, and give the client a way forward. Avoid long apologies. Millo's advice is not to write novel-length emails apologizing for having to charge.
When the request needs a price
Hi Sam, thanks for sending this. A blog isn't part of the current agreement (the scope covers the five pages we listed), so I'd treat it as an addition. Based on what you described, I estimate about 6 hours, which would be $540, and it would move launch by two days. If you'd like to go ahead, reply "approved" and I'll schedule it. If you'd prefer to keep the current date and budget, we can add it after launch.
Get Matthew Evans’s stories in your inbox
Join Medium for free to get updates from this writer.
When you offer a trade-off
Hi Priya, I like the idea of adding a pricing page. To keep the launch date and budget as agreed, we could swap it for the testimonials slider. Would you like to make that swap, or add the pricing page as extra work after launch?
When you need clarification
Hi Daniel, before I can tell you whether this fits the current scope, could you tell me what you want visitors to be able to do in that section? Once I know, I'll confirm whether it's included or needs a quote.
When you defer
Hi Maria, that's a good addition. To protect the launch date, I've put it on a list for the next phase. After the site is live, I can scope it properly and send you a quote.
The costs and timelines above are illustrations. Use your own rates and estimates.
Step 7: Record the decision and get approval before you start
If the work changes the price or the date, get written approval first. Wethos recommends sending a change order that lists the new deliverables and costs. It can be as simple as an email, as long as it's written and approved before extra work begins.
For every request, keep a log with:
The request and its date
The outcome (included, clarify, trade, extra, or defer)
Estimated time, cost, and delivery impact
What you told the client
Approval status and date
This log is your reference when a client later says, "I thought that was included." You can point to the date, the decision, and their approval.
Common mistakes to avoid.
- Saying yes first and pricing later. Once you’ve started, you’ve set the expectation.
- Quoting off the cuff. Rushed numbers are usually too low.
Treating small requests as free forever. Speckyboy notes that a collection of small requests often adds up to the painful kind of scope creep. Set a rule for what counts as a quick tweak, and track the rest. - Discussing changes only by phone. Follow up in writing so decisions exist somewhere.
Starting extra work without approval. The client can fairly say they never agreed to the cost. - Never revisiting your scope document. If the same request keeps coming up, your scope template needs a clearer line.
A repeatable checklist for every change request
Capture the request in the client’s words.
Ask what they’re trying to achieve.
Compare it with the written scope.
Choose: included, clarify, trade-off, extra, or defer.
Estimate time, cost, and delivery impact.
Reply in writing with a clear option.
Get written approval before extra work.
Log the decision.
Where a system helps
You can run this process with a spreadsheet or a notes app. The hard part is doing it consistently when you’re busy and a client is waiting for an answer.
The Client Change Tracker is a Notion-based change request system built for solo freelance web designers and developers on fixed-price projects. It gives you a structure for the steps above: project scope setup, a request intake, a 2-Minute Decision Tool, an impact calculator, professional response templates, a change log, and a reference library of common website change requests.
It isn't a CRM, invoicing tool, contract generator, project management system, or client portal. It won't write your contract or guarantee a client agrees. It's meant to help you make more consistent decisions and answer clients with less improvising.
Frequently asked questions (FAQs)
- What counts as an out-of-scope request on a website project?
Anything not covered by your written agreement, such as extra pages, new features, or design changes beyond your agreed revision rounds. If the agreement is vague, treat the request as "needs clarification" first.
- Should I charge for every small change?
Not necessarily. Many freelancers absorb tiny tweaks (Payoneer’s example is a font change that takes minutes) and charge for anything substantial. Decide your threshold in advance and apply it consistently.
- How do I charge for additional website work?
Estimate the time and cost, send the quote in writing, and wait for approval. Options include an hourly rate for extras or a fixed add-on price. Freelancers in an Upwork community thread suggest offering a new milestone for added work on a fixed contract.
- What’s the difference between a revision and a change request?
A revision refines work already within scope, up to your agreed rounds. A change request adds, replaces, or expands what was agreed. Define both in your contract.
- Can I say no without losing the client?
Usually, yes. Acknowledge the idea, explain what the agreement covers, and offer a way forward: price it, swap it, or defer it. A clear process reads as professionalism.
- What if I never wrote down my scope?
Stop and write one now, share it with the client, and get confirmation of what has been agreed so far. Then handle new requests against that document.
Your next step
Pick your next live project and write down the scope in specific terms. Then run every new request through the eight-step checklist above.
If you'd rather start from a ready-made system than build one, the Client Change Tracker is designed for exactly this workflow for freelance web designers and developers. It won't remove every difficult conversation, but it gives you a consistent way to handle them.
