Specific client requests we're asked about often \u2014 whether each is out of scope, the clause usually involved, and wording you can adapt.
Usually yes, beyond a basic consent banner. Full cookie-category management and legal-compliance configuration go beyond design scope.
Yes. Single sign-on is a security-critical authentication feature requiring real engineering and identity-provider integration — not something a design engagement builds, even where the design covers what the login screen looks like.
Usually yes. A blog is a new content type and template, not a variation on the pages the project already scoped — even on a CMS that technically supports posts out of the box.
Yes. A booking system needs backend logic and availability data, not just an interface.
Usually a small styling task, not the integration itself — most chatbot tools are drop-in scripts, so the design-only part of the ask is genuinely minor, but the setup/configuration around it isn't.
Yes. Authenticated areas involve their own UX patterns (login, password reset, gated content states) that a public marketing site's design scope typically never accounted for.
Yes. Wiring up a payment processor is a backend development task, not a design one.
Yes. Environment setup is infrastructure work, not a design deliverable.
Usually yes, unless it was named as a requirement up front. WCAG compliance is a defined standard with specific, often extensive design implications (contrast ratios, focus states, content structure) — it's a deliverable in its own right, not something a design naturally has by default.
Yes. An affiliate/referral program is a functional system with its own dashboard and logic, not a design deliverable.
Yes. The proposal priced a specific page count, and a landing page beyond that count is additional design work, even if it reuses the same visual style as the rest of the site.
Usually yes. A/B testing needs a genuinely separate variant designed and built — a second version of the page, not a tweak to the one that was scoped — even when it reuses most of the same content.
Yes, past the approved motion concepts. New animation ideas after sign-off are revisions to an already-approved deliverable.
Yes. A second full theme with its own palette and contrast decisions is a distinct design deliverable.
Yes, clearly. Product pages, cart, and checkout are a fundamentally different design problem than a marketing site, and belong nowhere near the original scope regardless of how the request is phrased.
Yes. Local SEO — location pages, listings, map optimization — is an SEO deliverable, though a design agency may legitimately design a new location page's layout if asked to.
Usually yes. Motion graphics — animated titles, lower thirds, transitions — are additional production work beyond the video that was scoped and delivered, not a small polish pass.
Yes. Roles and permissions are application logic — controlling what different users can see and do — not a visual design concern, even where the design shows what different views might look like.
Yes. Paid search is a media-buying and ad-platform discipline with no overlap with design deliverables.
Mostly yes. The visual side (a permission prompt, a notification-preferences UI) is arguably design work, but the underlying system — service workers, permission handling, a way to actually send notifications — is functionality a design engagement typically doesn't cover.
Yes. Wiring up a live chat tool is a technical integration, not a design deliverable.
Yes. Structured-data markup is a technical SEO task, not a design deliverable.
Usually yes. Social templates are a distinct deliverable — a different canvas size, format, and design system than the web pages the project scoped — even when they reuse the same brand elements.
Usually yes. Translated subtitles need accurate translation and re-timing against the video — a distinct deliverable beyond the video project as originally scoped, even where the original video was a bundled design deliverable.
Yes. The engagement is scoped to the website property — a native or mobile app is a different product with a different design system.
Yes. Competitive/site auditing is research work outside a design deliverable list, even when the acquired site will eventually be redesigned by the same agency.
Usually yes. A reusable component library is a distinct system-design deliverable beyond the specific pages quoted.
Yes. A CRM integration is backend engineering work — API connections, data syncing, error handling — entirely outside what a design engagement covers, even when the form or UI it connects to was designed as part of the project.
Yes. A dashboard is an internal application UI with its own information-density and interaction-design demands, fundamentally different from designing public marketing pages.
Yes. A custom dashboard is a data application, not a marketing-site design deliverable.
Yes. If the deliverable was a set of form templates, a fully custom one-off form is new design and layout work beyond that library.
Yes. Plugin and module development is engineering work, not design.
Yes. A live, interactive reporting dashboard is an application feature — data pipelines, visualizations, a UI that updates — not a design deliverable, even when the visuals resemble the charts and layouts a design engagement might otherwise produce.
Yes. A native or cross-platform app is a different medium with its own interaction patterns and platform guidelines — not a responsive breakpoint on the website, even when the client thinks of it as "the same design, just for phones."
Yes. Connecting a signup form to an email marketing platform's API is technical integration work, not a design deliverable.
Yes. An internal tool is functional software for staff use, not a public-facing design deliverable.
Yes. Backlink building is an SEO/outreach discipline unrelated to designing pages for a new product line.
Yes. A client portal is a distinct application with its own login, permissions, and interface — not a page added to the marketing site.
Yes. Content strategy and scheduling for social or other channels is marketing work outside a design deliverable list.
Usually yes, if the quote priced a standard template 404. Fully custom illustration and copy is a distinct design deliverable.
Usually yes. Once a color palette has been approved as part of the visual direction, a request for a genuinely new palette is a new exploration round, not a revision within the one that was already signed off.
Usually yes. A presentation template is a different format and deliverable than a website — it draws on the same brand system, but the layout, format, and design considerations are distinct.
Yes, if email templates weren't in the original deliverables — email design has its own constraints (client rendering quirks, inline CSS) distinct from web page design and is typically scoped and priced separately.
Yes. Video production for paid social ads is a different medium, skill set, and often a different discipline (paid advertising) entirely from designing a website, even where the same brand assets are reused.
Usually yes, once the agreed number of concepts has been delivered and a direction chosen. Additional concepts beyond that are a new exploration round, priced the same way any revision-limit overage is.
Usually yes, once the final cut was approved. If a video (a homepage hero video, an explainer piece) was a bundled deliverable within the design project, its revision rounds are typically capped the same way any creative deliverable's are — further edits after approval are a new round.
Yes. SEO strategy and market expansion aren't design deliverables, even if the site's design needs to accommodate a new locale.
It depends on what the "bug" actually is. A genuine defect in what was delivered — something that doesn't match the approved design or doesn't work as built — is typically covered by warranty. A new issue introduced by later changes, or a request framed as a bug that's really a new feature, is not.
Yes. Layout breakage from a client's own CMS edits isn't a design defect covered by warranty.
Yes. API integration is a development task even when it's triggered by a design decision (e.g. a new booking widget) — design scoped the visual system, not backend integration work.
Yes. Tracking search rankings for keywords is an SEO reporting deliverable with no design component.
Yes. Link building is an SEO discipline entirely separate from design work, even on projects where SEO-friendly design choices were part of the brief.
Yes. Load testing is a technical performance verification task, not a design deliverable.
Yes. Reconnecting tracking codes and analytics properties is technical implementation work outside a design deliverable list.
Usually yes. Most design engagements only cover a launch onto whatever host was agreed at the outset — moving the finished site to a different provider later is separate technical work, not a design revision.
Usually yes. A brand guidelines document is typically a defined deliverable with a set number of revision rounds — a second, substantially different version after approval is a new deliverable, not a revision.
Usually yes. A second explainer video is a full new production — script, voiceover or motion, editing — beyond the one video the project scoped, even when it covers a related topic.
Yes, without a separate agreement. A closed design project doesn't carry an implied ongoing update commitment.
Usually yes, once approved. Business cards are typically a small add-on deliverable within a brand/collateral package — approved work is covered by the included revision rounds, but a full redesign after approval (especially after printing) is a new round.
Yes. Once a design is approved and the project has launched, a request to redesign a page — as opposed to fix a bug in it — is new design work, not a continuation of the original engagement.
Yes. Interpreting and reporting on analytics data isn't a design deliverable.
Depends. A genuine defect in the delivered footage (bad audio, a visible mistake) is covered under warranty; a reshoot because the client's preference changed is a new revision beyond the agreed round count.
Yes. A/B testing tooling is technical infrastructure, not a design deliverable — though designing test variants may be a natural add-on.
Yes. CI/CD pipeline setup is a development-infrastructure task with no design-deliverable overlap.
Depends. Designing for a broader viewport range is usually included; a genuinely new device class (e.g., a specific kiosk display) often isn't.
Depends. A brief CMS content-editing walkthrough is often included; structured, repeated staff training usually isn't.
Yes. Translation itself and the layout adjustments a second language often requires (text expansion, RTL support) are additional design and production work beyond a single-language build.
Yes. A CMS version upgrade is a technical and infrastructure task, not a design one.
Yes. Technical documentation for a dev team is a writing deliverable outside a design engagement's scope.
Yes. Content writing — and any monthly quota of it — is a content/SEO retainer deliverable, not a design one, even on a project that included setting up the blog itself.