Skip to main content

Scope creep for web developers: where projects actually break

Web development scope creep usually hides in the gap between 'build this feature' and 'make it work in production.' Clients think the feature is the deliverable; you know the feature plus browser support, analytics, CMS setup, staging parity, and handoff docs is the deliverable. Your contract has to name the boundary — or the boundary will be drawn in your unpaid hours.

Patterns to watch for

  1. 01The 'and it should work on…' expansion

    Scoped for 'modern browsers' turns into 'and IE11' or 'and the client's specific Android tablet.' Every additional browser or device is a testing matrix multiplier. Your contract should name supported browsers and versions explicitly — everything else is a change order.

  2. 02The integration that wasn't listed

    You built the contact form. The client says 'just wire it up to HubSpot, Mailchimp, and their internal CRM.' Each integration is its own auth model, schema, error surface, and testing cycle. Integration work grows non-linearly — three CRMs is not 3x one CRM.

  3. 03The content-entry workload

    You built the CMS-driven site. The client assumes 'you'll load in the content, right?' You didn't quote for content entry — that's hours of copy-paste, image sizing, URL slugs, and SEO fields. Contracts should explicitly state whether content entry is included, and if so, for how many pages.

  4. 04The post-launch 'tweaks'

    After launch, the client sends a steady stream of copy changes, image swaps, and layout nudges as if you're on retainer. You're not. Your contract should name a post-launch adjustment window (e.g., 14 days for bug fixes only) and a separate support agreement for ongoing changes.

  5. 05The performance goalpost shift

    You shipped a fast site. Post-launch, the client runs PageSpeed Insights and sends you the report. Getting from 85 to 95 on Lighthouse can be more work than getting the whole site built. Performance targets must be in the contract as specific numeric thresholds, or not in the contract at all.

Red flags

  • Vague browser or device language ('works on all major browsers').
  • The client has never actually listed the CMS they want to use until mid-project.
  • 'You'll handle content loading, right?' — asked casually, after contract signing.
  • Requests for 'just a small tweak' to the staging environment after sign-off.
  • Analytics, SEO, or tracking tools mentioned for the first time near launch.
  • Mid-project mention of a specific compliance requirement (GDPR, HIPAA, accessibility audit) that wasn't in the original brief.
  • The client wants to 'test' the site on a device or browser not listed in the agreement.

How to respond

When a web development scope ask lands, the most useful response is to name the specific technical work involved and translate it into hours, not features. 'Adding Mailchimp integration is ~6 hours: schema mapping, error handling, double opt-in flow, and staging tests. Happy to include it as a change order.' This tells the client three things: you know what you're doing, the work is non-trivial, and you have a billing mechanism for it. Avoid saying yes to 'quick' integrations verbally — always send a written estimate first, even if it's a one-liner.

Settled reads your contract and gives you the exact verdict for this situation — try it free →

Frequently asked questions

What browser/device support should I commit to by default?+

The last two major versions of Chrome, Firefox, Safari, and Edge on current-generation desktop OSes; iOS and Android's current and previous major versions on Safari and Chrome. Everything beyond that — older browsers, specific enterprise environments, non-mainstream OSes — is an add-on. Put the support matrix in an appendix to the contract.

How do I scope content loading without losing the project?+

Offer two tiers: a 'skeleton launch' where the client loads their own content, and a 'full launch' with content entry included, priced per page. Most clients pick skeleton launch once they see the price of full launch, which is the outcome you want.

The client is asking for a Lighthouse score of 95+ post-launch. Am I obligated?+

Only if the contract specified a numeric performance target. If it didn't, performance optimization beyond reasonable defaults (compressed images, minified bundles, sensible caching) is new work. Quote it as a fixed-fee optimization project with a measurable goal.

What's a reasonable post-launch bug-fix window?+

Most freelance web contracts give 14 or 30 days post-launch for genuine bug fixes — functionality that doesn't work as specified. That window does not cover copy changes, design tweaks, or feature additions. After the window, bug fixes become billable too unless you've agreed to an ongoing support retainer.

Should I include analytics setup in my default scope?+

Name it explicitly either way. If you're including basic GA4 or Plausible setup, list it as a line item with a fixed scope ('installation + a single pageview event + a goal configuration'). If the client wants a custom analytics stack — server-side tracking, multi-tool integration, custom dashboards — that's a separate engagement.

How do I price an integration I haven't built before?+

Spike on it first. Spend a paid discovery hour reviewing the integration's docs and auth model, then quote based on what you've learned. Do not quote integrations sight-unseen — third-party APIs have dramatic variance in ergonomics and edge cases, and a bad quote will eat your weekend.

Related reading

Answer scope creep from your actual contract — not a template.

Settled reads your contract and the client's request, gives you a verdict (In Scope / Out of Scope / Ambiguous), and drafts the email grounded in your specific clause.

Try it free →Read the scope creep guide