Skip to main content
Out of Scope

is tacking on a deliverable the contract never listed out of scope?

Yes — a deliverable that isn't on your contract's list is, almost by definition, outside the agreed work; the list is what defines the deal. The only exception is when a clause promised an open-ended quantity or a category broad enough to swallow the new item.

Why this answer

The deliverables list is the spine of a freelance contract. Everything else — the fee, the timeline, the revision rounds — is calibrated against that specific set of outputs. So when a client adds an item the list never named, the logic is unusually clean: the new deliverable wasn't priced, wasn't scheduled, and wasn't agreed, which makes it new work by the plainest possible test. The reason this one feels harder than it is comes down to framing. Clients rarely say 'I'd like to commission an additional deliverable'; they say 'oh, and can you also do the X while you're at it,' as if proximity to the existing work makes it part of the same job. But adjacency isn't inclusion. A deliverable sitting next to scoped work, sharing a project or a theme, is still a separate output that consumes separate effort. The honest framing for the client is that the contract bought a defined set of things, and a thing not in that set is a thing not yet bought. That's not a refusal — it's just an accurate read of what the agreement covered.

When the answer flips

It tilts away from Out of Scope when the contract's deliverables clause used open or categorical language rather than a fixed enumerated list. A clause promising 'social assets for the campaign' arguably absorbs a new asset of that type, where a clause naming 'three social posts' clearly does not. It also softens when the new item is trivial and so tightly bound to a listed deliverable that it reads as finishing the same job — a single export, a minor companion file — rather than a standalone output. The flip stays firmly toward Out of Scope when the new deliverable is its own substantive piece of work: a different format of output, a new channel, an added page, an extra asset that would have carried its own line and its own price had it been scoped at the start.

What to do next

Treat the new deliverable as what it is — a new commission — and make adding it easy rather than adversarial. Point gently at the deliverables list: 'The contract covers these specific pieces, and that one's a new addition — happy to fold it in as its own line.' Quote it the way you'd quote it fresh: a standalone item with its own scope, fee, and a note on whether it shifts the timeline, because a new output often does. Resist the 'while you're at it' gravity that makes added work feel free; bundling it silently into the existing fee trains the client to keep tacking on. A one-line change order is usually all it takes — it keeps the addition clean, documented, and unambiguous about price. And when the client sees it priced reasonably and offered without friction, the answer is far more often 'yes, add it' than any pushback you might have feared.

Frequently asked questions

The new deliverable is small and related to what I'm already doing. Is it really separate?+

Relatedness and inclusion aren't the same thing. A small item that lives near your scoped work is still its own output if it takes its own effort and would have carried its own price at the start. The test isn't whether it's adjacent to the project — almost everything a client adds is adjacent — it's whether it's a distinct thing the contract named. If it's a genuine companion to a listed deliverable, a single export finishing the same job, absorb it. If it's a standalone piece wearing 'small' as a costume, scope it.

My deliverables clause is a bit vague. Does the new item count as included?+

It depends on whether the clause is categorical or enumerated. Language like 'social assets for the launch' is a category, and a new asset of that kind can fairly fall inside it. Language like 'two banner ads and one email' is a list, and anything outside those exact items is new work. Read your own clause honestly: if it's broad enough to genuinely cover the new ask, honor it this time, then tighten it to an enumerated list next contract so the boundary stops depending on interpretation.

How do I price an added deliverable mid-project?+

Price it as if it were arriving fresh, not as a discount on the existing job. Scope the new item on its own terms — what it takes to produce, what it's worth — and quote a standalone fee rather than folding it into the original number. Mid-project context can save you some discovery time, which you can reflect, but don't let proximity to ongoing work pull the price toward zero. A clean separate line also keeps your records honest about what was originally agreed versus what got added along the way.

The client says they assumed this was obviously part of the project. Now what?+

Assumptions don't expand a contract, but they do deserve a respectful reply. Acknowledge that it might have felt implied, then point to the deliverables list as the actual definition of the work: 'I can see why you'd think so — the contract scoped these specific pieces, and this is a new one I'm glad to add.' Don't argue about what was obvious; redirect to what was written. If the clause really was ambiguous enough to support their reading, extend a little grace this once and remove the ambiguity going forward.

Will adding a deliverable push the deadline, and who absorbs that?+

It usually does, and the client absorbs it, because a new output needs real time you hadn't allocated. When you quote the added item, state its timeline impact in the same breath: this addition moves delivery by roughly this much, or it can run in parallel for an additional cost. Making the schedule consequence explicit prevents the common trap where a client agrees to the fee but still expects the original date. Treat fee and timeline as the linked pair they are — the new deliverable changes both.

How do I keep this from happening repeatedly on the same project?+

Set the precedent early and keep the list visible. The first time you handle an addition cleanly — named as new work, priced, change-ordered — you teach the client how adds work on this project, and the casual 'while you're at it' requests usually slow down. Reference the deliverables list in your status updates so the agreed set stays present in everyone's mind. And write contracts with an enumerated list plus a short line stating that items beyond it are quoted separately, so each new ask has an obvious, pre-agreed path.

Answer scope creep from your actual contract — not a template.

Settled reads your contract and the client's request, gives you a verdict (In Scope / Out of Scope / Ambiguous), and drafts the email grounded in your specific clause.