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 banner script. A full consent-management platform with script-blocking logic is a distinct technical build.
Yes, unless it was named in the original feature list. SSO means integrating with external identity providers, handling SAML/OIDC protocols, and building secure fallback behavior — a substantial security-sensitive feature, not a config toggle.
Usually yes. A blog needs its own data model, templates, and content-entry workflow — build work the original scope of functionality didn't include, even on a platform where posts are a built-in content type.
Usually yes, unless it was specifically named in the original quote as a deliverable.
Depends on the depth requested — a drop-in script embed is minor; connecting the chatbot to backend data (order status, account info) is a real integration outside a typical build's scope.
Yes. Authentication is a real feature with security implications (password handling, session management, access control) — never a minor add regardless of how the request is phrased.
Yes, if it wasn't part of the original deliverables. It's native dev work, but payment integration carries real complexity and liability, so it needs its own scope.
Usually yes, unless the original quote already specified a staging environment as a deliverable.
Usually yes, unless the SOW named a specific conformance level. WCAG compliance touches semantic markup, keyboard navigation, ARIA attributes, and focus management throughout the build — real engineering work, not a settings toggle.
Usually yes. Building referral tracking, unique codes, and payout logic is a substantial standalone deliverable.
Yes. The functional build was scoped to a specific set of templated pages, and a new page — even from an existing template — is additional build and QA work beyond what was quoted.
Usually yes. Building and deploying a second variant — and wiring up traffic-splitting between the two — is real implementation work beyond the single page the build was scoped around.
Yes. Building motion effects the approved design didn't specify is additional implementation work beyond the build.
Yes, unless it was quoted. Toggle logic, persisted preference, and per-component styling for a second theme is real added build work.
Yes. Cart, checkout, payment processing, and inventory logic are substantial features with real security and compliance surface area — never an incidental add to a site build.
Yes for the SEO strategy, though building an actual new location page or updating structured data is legitimate development work if scoped as such.
Yes. Motion design is production work with no overlap with development, regardless of where the finished video is embedded.
Yes, unless it was named in the original feature list. A permissions system means defining roles, enforcing checks throughout the application, and testing every access path — real, security-relevant work, not a config flag.
Yes. Managing ad accounts and bidding strategy has no technical overlap with development work.
Yes, unless it was named in the original feature list. Push notifications need a service worker, permission handling, and typically a backend to trigger and send them — a real feature with its own infrastructure, not a small add to an existing build.
Yes, if it wasn't in the original deliverables. It's native dev work, but a live chat integration is a new feature with its own setup and testing.
Yes, if it goes beyond the schema types listed in the quote. Implementation is dev work, but the original quote defines which types were included as deliverables.
Yes. Social media templates are static design assets, not something a development engagement produces — outside the scope regardless of whether the request is routed to the dev team for convenience.
Yes. Translation and captioning work isn't a development discipline, and this holds regardless of whether the video is technically embedded in a site the dev team built.
Yes. A mobile or native app is typically a different codebase and platform than the website the engagement covers.
Yes. A technical audit of a different site is real analysis work outside the current build's scope, whatever future work it might inform.
Usually yes. A generalized, reusable code component library is more work than building the components a specific site needs.
Yes, unless it was named in the original feature list. A CRM integration means real API work, authentication, field mapping, and error handling — a genuine feature, not a config change, even for a common CRM with an existing API.
Yes. A dashboard means new data models, auth/permissions logic, and CRUD interfaces — a substantial application build, not an extension of a public site.
Usually yes. Pulling and displaying live analytics data in a custom interface is a distinct application build.
Yes. Building and wiring up a fully custom form — validation, submission handling, integrations — is more effort than configuring an existing template.
Yes, if it wasn't named in the original deliverables. It's native dev work, but a custom plugin is substantial, unquoted effort.
Yes, unless it was named in the original feature list. A reporting dashboard means a data pipeline, storage, and a UI to visualize it — a genuine feature build, not a small addition to an existing app.
Yes. A native or cross-platform app is a different codebase, stack, and deployment process (app store review, platform-specific APIs) than a website — not an extension of the existing web build regardless of how much backend logic could theoretically be shared.
Usually yes, unless the original quote specifically listed an email-platform integration as a deliverable.
Usually yes. An internal tool is a separate application build, quoted (or not) on its own terms.
Yes. Backlink outreach has no technical component the dev team would own, regardless of building the product-line pages themselves.
Usually yes. A portal is a full application build — auth, data models, permissions — well beyond a marketing site's development scope.
Yes. Content strategy and scheduling have no technical component and no overlap with development work.
Yes, past implementing the standard template. Custom logic (dynamic suggestions, search, tracking) is separate build work.
Yes. This is design work, and on a development-only engagement it's outside the scope regardless of how small it sounds — the dev team implements a palette, it doesn't create one.
Yes. A presentation template is a design deliverable in a completely different format than a website build, and outside a development engagement's scope regardless of who's asked.
Yes, if transactional/marketing email wasn't part of the original build — coding and testing email templates across clients is its own workstream, separate from the site build even when triggered by site events.
Yes. Video production has no overlap with building or maintaining a website and isn't something a development engagement covers under any framing.
Yes. Logo design is brand identity work, unrelated to a development engagement's scope regardless of who the request is routed to.
Yes. Video editing isn't a development discipline at all, and this holds whether or not the video appears somewhere on the site the dev team built.
Yes, as strategy — though technical support like hreflang tags or a new locale's URL structure is genuine development work if it's already part of the build.
It depends on the cause. A defect that traces back to the build itself is typically covered by warranty; a bug introduced by something that changed afterward — a dependency update, the client's own code changes, a third-party integration — is a separate, billable investigation and fix.
Yes. Breakage from a client editing code or config directly isn't a defect covered by warranty.
Usually yes, unless it was named in the original feature list — a new integration brings its own auth, error-handling, and ongoing-maintenance surface the SOW didn't budget for.
Yes. Rank tracking and SEO reporting are unrelated to building the site's technical infrastructure.
Yes. Link building is outreach and marketing work, unrelated to development regardless of how technically SEO-conscious the build was.
Usually yes, unless it was specifically quoted. Simulating real traffic load and tuning for it is a distinct pre-launch deliverable.
Depends. If this team's own redesign broke tracking that was previously working, that's a defect to fix under warranty. If it's a full re-implementation of tracking that was never live before, that's new scope.
Usually yes. Migrating a live build to a new provider means re-provisioning infrastructure, moving data, and testing the cutover end to end — real engineering work distinct from building or maintaining the site on the host it was built for.
Yes. Brand guidelines are a design deliverable, not something a development engagement produces, regardless of who the request is routed to.
Yes. Video production isn't a development discipline, regardless of whether the finished video ends up embedded in the site the dev team built.
Yes, without a separate agreement. Bug fixes and updates after a closed build require a maintenance arrangement.
Yes. Business card design is print/graphic design work, unrelated to building or maintaining a website, and outside a development engagement regardless of who the request is routed to.
Yes. If the build shipped against an approved design and the client now wants the homepage rebuilt to a different design, that's a new build, not a bug fix or leftover task from the original project.
Yes. Implementing tracking is a technical task; interpreting and reporting on the resulting data is not.
Yes. Video production and reshoots are outside a development engagement regardless of whether the footage was ever embedded on the site being built.
Usually yes, unless it was quoted. A testing platform, traffic-split logic, and results tracking is a distinct technical build.
Usually yes, unless the original quote already specified an automated deploy pipeline.
Yes, past the agreed matrix. Extra compatibility testing and fixes for a new target take real QA time.
Depends. A standard technical handoff session is usually included; ongoing or multi-team training typically isn't.
Yes, unless internationalization was explicitly scoped from the start — adding a second language after a single-language build usually means retrofitting i18n infrastructure the original architecture didn't include.
Usually yes. It's native dev work, but a major-version upgrade is a significant, higher-risk undertaking beyond routine build or maintenance work.
Usually yes, unless documentation was explicitly listed as a deliverable in the original quote.
Yes. Writing content is unrelated to building the technical infrastructure a blog runs on, regardless of how the two get bundled in conversation.