What a fixed-scope proposal actually looks like

"Fixed scope" is a phrase every agency uses and few actually deliver on cleanly. We think the best way to show what we mean is to walk through the actual shape of a real proposal, with client specifics removed, rather than describe the concept abstractly the way most agency marketing content does.

A real proposal from us names every page template, every integration, and every piece of content we're responsible for, as a literal checklist: "12 page templates, product catalog sync with existing inventory system, blog migration of 40 existing posts with redirects, contact form with CRM integration." If it's not on the list, it's not included, and both sides know that before signing rather than discovering it during a scope disagreement in week six.

We format this as a numbered list specifically so it's easy to reference later. If a question comes up mid-project about whether something was included, the answer is a line number in a document both sides already agreed to, not a memory of a conversation from two months earlier.

We don't quote "$18,000 to $24,000." We quote $21,000, having already scoped the specific deliverables list closely enough to commit to a single figure. A range is usually a sign the scoping conversation didn't go deep enough yet, and we'd rather have that conversation before the proposal than let a range absorb the uncertainty silently.

Clients occasionally push for a range anyway, expecting more negotiating room. We explain instead that the single number already reflects real scoping work, and that a lower number would mean a shorter deliverables list, not the same list at a discount.

Not "8 to 10 weeks." A week-by-week breakdown: week 1 to 2 discovery and wireframes, week 3 to 5 design, week 6 to 8 development, week 9 QA and content migration, week 10 launch. Clients can see exactly where their own review and feedback windows sit in that timeline, which is usually where delays actually come from, not from our own production time.

Naming the review windows explicitly does something a vague range never does: it makes the client's own responsiveness a visible part of the schedule rather than an invisible variable. If a client knows week 4 is their two-day design review window, and they let it slip to a week, they can see directly why launch moved by five business days rather than assuming the agency simply ran behind. That visibility has resolved more timeline disputes for us than any amount of buffer padding ever did.

Every proposal includes a short paragraph on what happens if the client wants something added mid-project: it gets scoped and priced as an addendum before work starts on it, not absorbed silently into the existing budget or refused outright. This one paragraph prevents more mid-project friction than almost anything else in the document.

We've found that naming the process matters more than the process itself. Most clients never actually need it, because most projects don't generate a genuine mid-project addition. But the ones that do are exactly the projects where an unnamed process would have caused a dispute, either because the agency absorbed the work silently and resented it, or because the client assumed it was already covered and felt blindsided by an unexpected invoice line. A single paragraph, agreed to before either scenario happens, removes the ambiguity entirely.

Every proposal also has an "out of scope" section naming things we specifically aren't doing: ongoing hosting management, content writing beyond migration, third-party subscription costs. Clients occasionally find this section blunt, but it prevents a much worse conversation later where an assumption goes unstated until it becomes a dispute.

We started writing this section explicitly after a handful of early projects where a client assumed something was included simply because it seemed adjacent to what was included, ongoing SEO monitoring after a launch, say, when the proposal only covered the technical SEO setup itself. Naming the boundary in writing, even when it feels slightly unnecessary for a given client, has consistently been worth the mild awkwardness of stating it plainly upfront.

Rather than a flat 50 percent upfront and 50 percent on completion, we tie payments to specific milestones: deposit at signing, a payment at design approval, a payment at development complete, final payment at launch. This gives both sides a clear, mutually visible signal of progress, not just a calendar date.

This structure also protects the client, not just us. If a project stalls after design approval for reasons outside anyone's control, only two of the four milestone payments have been made, which is a fairer position for a client than having paid half the total on day one.

Every milestone payment is tied to an explicit written sign-off, not an implied approval inferred from a lack of objection. We ask the named decision-maker to confirm design approval in writing before development starts, specifically because "they didn't say anything so we assumed it was fine" is a genuinely common source of dispute later, when a stakeholder who wasn't paying close attention during review suddenly has strong opinions after development is already underway.

A vague proposal feels flexible when you sign it and feels like a trap by week eight, when either side can plausibly claim something was or wasn't included. A specific proposal takes longer to write and occasionally loses us a client who wanted the vagueness to negotiate scope creep in later. We've made peace with that trade, because the clients who stay are the ones who value knowing exactly what they're getting.

We've also noticed a second-order benefit that wasn't the original goal: writing this specifically forces us to actually think through the project in detail before quoting it, rather than pricing based on a rough gut sense of similar past work. A proposal this granular is as much a discipline for us as it is a courtesy to the client, and more than once the exercise of writing it has surfaced a scoping question we'd otherwise have only discovered mid-project.