Website Redesign Assumptions and Exclusions

Outcome Summary

• Clear assumptions and exclusions reduce scope creep by making “what’s included” visible before work starts.
• A good redesign proposal separates deliverables (what you will produce) from dependencies (what the client must provide).
• The easiest way to avoid disputes is to define what triggers a change request and how changes are handled.

What Revamp Actually Does (Truth Block)

• ✅ does
  • Generates an AI website redesign demo from a pasted website URL
  • Produces a shareable live preview link you can send to a client
  • Lets you iterate by adjusting inputs (including optional design preferences)
  • Offers code export on paid plans
  • Supports a credits-based workflow so usage aligns with your plan
• ❌ does not
  • Guarantee SEO, performance, or conversion outcomes from a redesign
  • Replace discovery, stakeholder alignment, or final implementation decisions
  • Automatically include third-party services (analytics, payments, CRM, etc.) unless you scope and implement them

The Core Problem

• Clients often assume a “redesign” includes copywriting, SEO, analytics, and new functionality—even when you only quoted design and build.
• Teams blur the line between “preview” and “production,” treating early concepts as contractual deliverables.
• Dependencies (access to hosting, CMS, brand assets, legal approvals) aren’t stated, so timelines and responsibility get contested.
• Stakeholders request “small changes” that are actually new scope because there’s no change-control language.
• Third-party tools introduce unknowns (permissions, billing, vendor limitations) that weren’t excluded up front.

Framework

• Start with a scope sentence that names the outcome, not the activities (example: “redesign the marketing site to a modern layout and visual system”).
• List deliverables as artifacts (what the client can point to), not effort (what you do).
• Add assumptions next: what must be true for your scope, timeline, and cost to hold.
• Add exclusions next: what you are explicitly not doing unless separately scoped.
• Define dependencies and ownership: who provides what, and by when (access, content, approvals, brand assets).
• Define change control: what counts as a change, how changes are approved, and what happens to timeline/cost.
• Align on acceptance: what “done” means (sign-off process, environments, handoff materials).
• If you pitch with a demo, label it correctly (preview vs production) and state what will be implemented.

Assumptions (copy/paste)

Use this when you want clarity without sounding defensive.

• The client will provide timely access to required systems (domain, hosting, CMS, analytics accounts, tag manager, email tools) and will confirm who can approve changes.
• The client will provide brand assets (logo files, fonts if licensed, color guidance) and any required legal copy.
• The client will supply or approve final page copy and images; content not supplied may be represented with placeholder content until approved.
• Feedback will be consolidated by a single point of contact; conflicting feedback may require a separate alignment step.
• Any third-party tools used by the client remain the client’s responsibility for billing, permissions, and vendor support.

Exclusions (copy/paste)

Use this to prevent “we thought that was included.”

• Copywriting, messaging strategy, and brand strategy (unless explicitly included in scope)
• SEO work beyond what is required for implementation (keyword research, content briefs, link building, technical audits)
• New product features or application functionality (accounts, dashboards, complex logic) unless separately scoped
• Ongoing maintenance, content updates, or on-call support after handoff unless covered by a separate agreement
• Procurement or management of third-party services (payment providers, CRM, chat widgets, marketing automation) beyond basic integration explicitly listed in scope
• Legal review, accessibility certification, security certification, or compliance sign-off

Language for “preview vs production” (copy/paste)

• “Any redesign preview or demo link is a concept visualization to validate direction. Final implementation details may change based on technical constraints, content, and stakeholder feedback.”

If you generate a demo in Revamp, you can share the preview link early to align on direction, then move into implementation with explicit assumptions/exclusions. (You can also draft proposal structure using the Website Redesign Quote + Proposal Generator.)

Use Cases

Agency pitching a redesign to win the project

• Scenario: A prospect asks for a redesign proposal and wants to “see something real” before committing.
• Recommended approach: Share a Revamp-generated redesign demo as a direction preview, then attach assumptions/exclusions that clarify what the signed scope includes (pages, integrations, content responsibilities, acceptance).
• Common mistake: Treating the demo as the final deliverable, which invites unlimited iteration and “just match the demo exactly” disputes.

In-house team modernizing an outdated marketing site

• Scenario: Marketing wants a refreshed site quickly, but engineering owns deployment and has constraints.
• Recommended approach: Use assumptions to define who owns implementation and what dependencies are required (access, CMS limits, component library constraints), and use exclusions to keep “new functionality” out of the redesign scope.
• Common mistake: Not excluding new features, which turns a redesign into a product build.

Freelancer rebuilding a small business site on a CMS

• Scenario: The client wants a redesign and expects you to also “handle hosting and email.”
• Recommended approach: Exclude vendor procurement and ongoing admin work unless you offer it as an add-on, and add assumptions about access and billing ownership.
• Common mistake: Taking ownership of third-party accounts without written boundaries, which leads to support obligations you didn’t price.

Decision Checklist

• Can the client tell the difference between direction preview (demo) and production implementation from your proposal?
• Are client responsibilities explicit (content, assets, approvals, access), including what happens when they’re late?
• Did you name the exact deliverables you will hand over (and what you will not hand over)?
• Are third-party tools and vendor limitations clearly excluded unless listed as deliverables?
• Is there a clear change-control rule that defines what counts as new scope?
• Do you have an acceptance process (who signs off, what counts as acceptance, where acceptance happens)?
• Is your scope written so a new stakeholder could read it and reach the same interpretation as you?

Constraints

• Assumptions and exclusions only work if they are referenced during feedback and change requests; otherwise they’re ignored.
• If you rely on third-party tools, you can’t promise timelines or outcomes that depend on vendor approvals or vendor uptime.
• A redesign preview can accelerate alignment, but it can also increase expectation—label it clearly and keep it tied to your scoped deliverables.
• Content delays commonly become implementation delays; your proposal should state how content readiness affects delivery.
• Some sites have complex functionality that a redesign concept doesn’t capture; scope discovery separately when needed.

Common Mistakes

• Writing assumptions as hidden fine print, which makes clients feel surprised when you enforce them.
• Excluding “SEO” too broadly, which causes confusion if the client expected basic redirects and metadata to be handled.
• Forgetting to define who provides content, which turns every missing paragraph into an emergency.
• Not naming third-party tools as dependencies, which shifts vendor risk onto you when logins, billing, or permissions block progress.
• Allowing multiple stakeholders to give uncoordinated feedback, which creates rework and conflicting direction.

FAQ

Where should assumptions and exclusions live in a proposal?

Put them near scope and deliverables, not at the very end. Clients should see them while they’re evaluating what they’re buying.

Should I include assumptions and exclusions if the project is “simple”?

Yes. “Simple” projects are where misunderstandings happen fastest because everyone assumes the details are obvious.

How do I handle revisions without promising a specific count?

Describe revision handling as a process: feedback is consolidated, changes are prioritized, and anything that changes requirements is treated as a change request.

What if a client asks for “just one more feature” mid-project?

Point to your change-control language and restate the impact: new scope requires approval and may affect timeline and cost.

Can I use a redesign demo as the basis for scope?

You can use a demo to agree on direction, but scope should still be written in deliverables and boundaries. Treat the demo as a preview, then specify what will be implemented.

How do I avoid being responsible for third-party tools?

Make ownership explicit: the client owns vendor accounts, billing, and vendor support. You only implement the integration that is listed in scope.