Scope changes

Scope changes are normal. They're not a problem if they're surfaced and priced honestly the moment they appear. They become a problem when they pile up unspoken until the launch date slips and someone has to eat the cost.

We handle them by surfacing them aggressively. If we think a request is outside the agreed scope, we say so the day we see it — not in the post-mortem.

How scope is defined

Your SOW lists the specific deliverables and services covered by the monthly retainer. Anything described in the SOW is in. Anything not described in the SOW is, by default, out of scope — and the contract requires written approval, a revised timeline, and (usually) additional fees before that work happens.

That's not adversarial; it's the discipline that keeps the monthly number stable for both sides. Without it, every conversation drifts toward "and while you're at it…" and the retainer stops covering the work.

During the build phase

Before launch, scope is defined by the SOW you signed at the start of the engagement. When something comes up that we think falls outside that scope, you get a written change request:

• What's changing — one paragraph explaining the new work.
• Why we think it's a scope change — what in the original SOW didn't anticipate it.
• The cost impact — additional hours, additional fee, or no impact (sometimes the answer is genuinely "no impact, we'll absorb this").
• The schedule impact — does it push the timeline or the launch date?
• Recommendation — our take on whether you should take it.

You decide. If you approve, we update the SOW with the change appended and the math reconciled. If you don't, we proceed with the original scope.

We do this even for small changes. Small changes pile up; making them visible makes the pile manageable.

Inside the ongoing retainer

After launch, the retainer covers reasonable ongoing updates under a fair-use policy (small content changes, image swaps, minor page edits — see what's in the retainer). Scope conversations only happen when a request falls outside fair use:

• Full redesigns
• Major feature additions
• New system integrations not contemplated in the SOW
• Rebuilding large portions of the site

When that happens you get a clear note before any work starts: what it is, why it's outside the retainer, the additional cost, and the additional time. You decide whether to greenlight it as separate scoped work, defer it, or scrap it.

We never start out-of-scope work and then surprise-bill you for it.

What's not a scope change

To be clear about what we don't treat as a scope change:

• Bug fixes for things in the original scope — those are part of delivery.
• Small wording / image / copy changes in the build phase — well within reasonable iteration.
• Decisions that have to be made during the build that the SOW didn't lock down.
• Work that's faster to do once than to debate — within reason, we just do it.

The bar for a change request is: "this work would meaningfully change the cost or timeline."

How we keep this honest

A few things keep this from devolving into a series of nickel-and-dime arguments:

• The SOW is specific enough that there's an actual document to point at.
• Sprint demos give you a regular checkpoint where surprises become visible early.
• We absorb genuine misjudgments on our part — if we said something would take 8 hours and it took 12, that's on us, not a change order.

If you ever feel like a change request looks more like a billing mechanism than a real scope expansion, push back. We'd rather lose the change order argument than have you doubt whether the next one is honest.

Where to go next

Minimum term & cancellation → Retainer model →