We were told our change is out of scope — is that fair or padding?

Ask one question. Does this change need something that does not exist yet, or does it rearrange things that do?

Most redesigns are built from a small set of components: a hero, a feature grid, a pricing table, a testimonial block, a form. Changing the colour, the spacing, the type size or the copy inside those components costs almost nothing, because the change is made once in the design system and every page inherits it. Adding a component nobody has designed, or a page type with a shape no other page shares, costs real days.

So a studio saying “out of scope” about a padding change on a card is probably protecting its schedule rather than its scope. A studio saying it about a case study template that does not exist in the agreed page list is almost certainly right.

The reason people misjudge this is that difficulty and structure feel like the same thing. They are not. A change can look enormous on screen and be a two-line token edit. A change can look trivial, one extra field on a card, and touch the content model, the CMS, the component and every page using it.

Sort your request into one of three buckets before you argue about it. In our projects, the bucket predicts the answer better than anything the client says about how small the change feels.

A useful sanity check: if the change can be described entirely in adjectives, it is a restyle. If it needs the word “new”, it is a rebuild.

• **Restyle.** Colour, type scale, spacing, corner radius, shadow, button style, copy inside an existing block. Made once in the design system, applied everywhere. Hours, not days. This should almost never be refused on cost grounds, and if it is, ask why.
• **Rearrange.** Reordering sections on a page, swapping one existing component for another, moving a field, cutting a block. Cheap, but not free, because the page has to be re-reviewed and the copy usually needs to shift with it. Half a day to a day per template, and it stacks if you do it after the page has already been approved.
• **Rebuild.** A new component, a new page type, a new content model, a new integration. Somebody has to design it, build it, wire it into the CMS so your team can edit it, and check it at every screen width. This is genuinely new work and a fixed-price project cannot absorb it silently.

You do not need to know how the site is built to test a refusal. You need the studio to answer in structural terms rather than in effort terms.

Ask these, in this order. The first two are free to answer and usually end the argument.

1. What changes structurally if we do this? New component, new page type, new content model, or none of those?
2. What did the original estimate assume here? Point me at the deliverable in the agreed scope.
3. What is the cheaper version of what I am asking for, using what already exists?
4. If we do this, what moves, the launch date or the invoice, and by how much?

A fair refusal is specific about the boundary and offers you a way to get most of what you wanted for nothing.

It names the agreed deliverable. “The scope has six templates, and a filterable resource index is a seventh” is a checkable statement. You can go and look.

It offers the cheaper version. When a client asks for an animated interactive pricing comparison and we quote it, we also say what the existing pricing table can do instead, and roughly what the alternative would have cost. Most clients take the free version, which is the point of offering it.

It arrives in writing before any money moves. On our projects nothing lands on an invoice that has not been approved in writing first, and each milestone is invoiced only after it is approved. A change note that says what is being added, what it costs, and what it does to the date is the normal shape of this. If you are being asked to approve a change verbally, ask for it in a message instead. Not because the studio is dishonest, but because six weeks later neither of you will remember the conversation the same way.

Padding talks about effort and avoids talking about deliverables. Each of these is a reason to push back rather than pay.

**Vague effort language with no object.** “That’s a fair bit of work” is not an answer. Which component, which template, which field? A studio that built the site can name the thing it has to touch in one sentence.

**No cheaper alternative offered.** Almost every request has a version that fits inside the existing system. A studio that never proposes one is either not thinking or not trying, and both cost you money.

**A price with no breakdown.** “That’ll be another two thousand” without design days, build days and review time behind it is a number pulled from the air. Ask for the split. You do not have to audit it, you just need to see that it exists.

**Everything is out of scope.** This is the clearest signal. When a colour change, a section reorder and a new template all get the same answer, the studio is not applying a boundary, it is defending a schedule it underpriced. In that situation the honest conversation is about the whole project, not about your change.

**A shifting boundary.** Two similar requests got two different answers, one absorbed and one billed. Ask what distinguishes them. Sometimes there is a real answer. Sometimes there is not.

Some requests are worth refusing on your own behalf, because you are paying for a worse site. These are the ones we push back on hardest, and the pattern repeats across projects.

**The one-off page type.** A page shaped unlike every other page needs its own design, its own CMS setup and its own maintenance forever. Six templates can drive hundreds of URLs. A seventh template that drives one URL is the worst ratio in the project. If the content can live in an existing template, put it there.

**The exception that leaves the system.** A client asked for one button in a different green because it matched a partner’s brand. That green is not in the token set, so it lives as a hardcoded value in one file. Nobody remembers it exists. Eighteen months later the brand shifts, every other colour updates from the tokens, and that one button stays wrong. One-off values are how a site starts looking untended.

**The late addition that moves the launch.** A request that arrives during page deployment costs more than the same request during foundations, because the thing it changes has already been designed, built and approved once. If a marketing site runs two to three weeks, a new component added in the final week is not a small edit, it is a re-run of a milestone. Write it on a post-launch list instead. The site is yours, the repository is yours, and adding a component in month two costs less than adding it in launch week.

**The change nobody can name a reason for.** If the only argument for it is that someone senior mentioned it, park it. Scope creep is rarely one big request. It is eleven small ones that each seemed free.

A refusal can be correct and still be a problem, and that is a different conversation from scope.

If the change you are asking for is the thing the site actually needs, the answer is not to argue about whether it was in the brief. It is to price it as an addition, decide whether it is worth the money, and move the date if it is. A studio that will not do that is telling you something about how it works.

And if you are three requests into a project and every one of them was outside the scope, the brief was wrong, not the studio. That is worth saying out loud early, because a scope agreed on a wrong brief gets more expensive to fix at every milestone.