Managing Website Iterations and Change Requests

Changes Are Normal

Every web project involves changes. Requirements shift, stakeholders have new ideas, and real users behave differently than expected. The goal isn't to eliminate change requests — it's to manage them so they improve the project without derailing it.

This guide covers how we handle changes at Webbfox, and how your team can make the process smoother.

During the Project

Structured Feedback Rounds

We build in dedicated feedback windows at key milestones — typically after wireframes, after visual design, and during development. Consolidating feedback into rounds is more effective than continuous one-off requests, which fragment attention and slow progress.

The Priority Question

When a change request comes in, we evaluate it against three criteria:

• Impact — does this meaningfully improve the user experience or business outcome?
• Effort — how much time does it add to the build?
• Timing — can it be done now without disrupting the current milestone?

Changes that score high on impact and low on effort go in immediately. Everything else gets logged and prioritised for the current phase or deferred to post-launch.

When to Defer

Not every good idea belongs in the first release. We actively encourage deferring changes that:

• Require content or assets that aren't ready yet
• Depend on user data you don't have until the site is live
• Expand scope beyond the agreed brief without a corresponding timeline adjustment

Deferring isn't saying no. It's saying "not yet" — and doing it well is one of the most important disciplines in web delivery.

After Launch

Post-launch is where iteration gets interesting. With real traffic, analytics, and user feedback, you can make informed decisions instead of guessing.

Support and Iteration Plans

Webbfox offers ongoing support plans that include a monthly allocation for updates, fixes, and small feature additions. This is the most efficient way to handle post-launch changes — predictable cost, clear prioritisation, and no need to re-engage from scratch.

Change Request Process

For clients on a support plan, the process is simple:

1. Submit the request — describe what you want changed and why
2. We assess and estimate — you'll get a scope and timeline within 48 hours
3. Approve and schedule — approved changes go into the next sprint
4. Review and sign off — changes are deployed to staging for your review before going live

Keeping Scope Healthy

The biggest risk in long-running engagements is scope creep — small additions that individually seem harmless but collectively consume the budget. We track all changes against the original brief and flag when cumulative additions warrant a scope conversation.

For a broader view of how projects flow from start to finish, see Webbfox Delivery Fundamentals. If you're just getting started, our kickoff guide covers what to prepare.