How to Stop Scope Creep on Website Projects

“Could we add another section to the homepage?”

Then:

“While you're there, can we make the case studies filterable?”

Then somebody else joins the project:

“I've just seen the site. Can we rethink the services section?”

None of these requests necessarily sounds unreasonable on its own.

But by the time the website launches, the agency may have delivered substantially more design, development, project management and QA than it originally priced.

That is where project margin disappears.

The solution is not to stop clients changing their minds. Changes are normal during website projects. The solution is to stop changes entering the project without an explicit decision about their effect on scope, cost and timeline.

A useful process is:

Request → Assess → Decide → Approve → Update → Build

Not:

Request → Build → Argue about the price later

That is the difference between controlled project change and scope creep.

What is scope creep on a website project?

Scope creep is the gradual addition or expansion of project requirements beyond the agreed scope without corresponding control over budget, timeline or resources.

For example, an agency agrees to build a marketing website containing:

• eight page templates;
• a case-study CMS;
• one HubSpot form;
• two design revision rounds.

During delivery, the client also asks for:

• a careers section;
• candidate file uploads;
• an HR-system integration;
• additional filtering;
• three more pages.

If those requests are simply implemented while the original budget and timeline remain unchanged, the scope has crept.

Current agency project-management guidance describes the same problem: additional features or tasks become scope creep when requirements expand without corresponding changes to resources, timeline or budget.

But an important distinction comes first.

Scope change vs scope creep: what's the difference?

Change itself is not scope creep.

Suppose a client asks for a location finder halfway through a website project.

The agency assesses the requirement and determines:

• additional design is required;
• development will cost £1,200;
• additional QA is needed;
• launch needs to move by approximately one week.

The client approves those changes.

The scope, project fee and delivery plan are updated.

That is a managed scope change.

Now imagine exactly the same request reaches a developer through Slack.

Someone says:

“Shouldn't take too long.”

The developer builds it.

Nobody changes the budget.

Nobody moves the deadline.

Nobody records that the scope changed.

That is scope creep.

PMI has long made this underlying point: project change is normal; the objective is not to eliminate change but to control it through impact assessment, approval and updates to the agreed project baseline.

The problem therefore isn't:

The client wants something different.

The problem is:

Something different is being delivered without anyone deciding what that difference means commercially and operationally.

Why are website projects so vulnerable to scope creep?

Website projects have several characteristics that make changing requirements particularly common.

Clients understand the website better once they can see it

A written requirement is abstract.

A wireframe is clearer.

A polished design is clearer again.

A working website is clearer still.

As the project becomes tangible, clients naturally think of things they did not consider during briefing.

That does not make them difficult clients.

It makes change management necessary.

PMI has specifically noted this pattern in website-related scope examples: stakeholders frequently develop additional ideas as they see the requested product taking shape.

Small visual changes can hide significant implementation work

A client might say:

“Can we make this filter slightly smarter?”

On screen, the difference may appear tiny.

Behind the interface it could require changes to:

• CMS architecture;
• filtering logic;
• URLs;
• front-end behaviour;
• responsive states;
• analytics;
• QA.

The perceived visual size of a request is not a reliable measure of implementation effort.

Website disciplines are interconnected

Adding one page may affect more than development.

It could require:

• copy;
• design;
• responsive layouts;
• CMS setup;
• internal links;
• navigation changes;
• SEO metadata;
• tracking;
• QA.

This is why “it's just one page” is not always commercially meaningful.

Stakeholders often arrive late

The marketing manager approves the design.

Development begins.

Then the founder sees the website.

Then sales comments.

Then legal asks for changes.

Previously approved work gets reopened.

This is less likely when approval authority and stakeholder involvement are defined before production begins.

“Revision” is often undefined

The agency thinks:

A revision means refining what we already agreed.

The client thinks:

A revision means anything I want changed before launch.

Unless those expectations are aligned, the revision allowance does very little to control scope.

1. Start with a scope clear enough to defend

You cannot identify scope creep if nobody can clearly state what the original scope was.

Before production begins, document the relevant project baseline.

That will usually include:

• sitemap;
• pages;
• unique templates;
• CMS requirements;
• functionality;
• integrations;
• content responsibilities;
• migration;
• technical requirements;
• revision rounds;
• QA;
• launch responsibilities;
• handover;
• exclusions;
• assumptions.

Do not rely on shorthand such as:

“CRM integration included.”

Define what that means.

For example:

Two agreed HubSpot forms using the existing native integration, including agreed fields, validation and confirmation states.

The more precise the baseline, the easier it becomes to distinguish a refinement from an additional requirement.

If the project cannot yet be described with this level of certainty, it may need further scoping before delivery begins.

2. Define revisions before design starts

A useful working definition is:

A revision changes an agreed deliverable while keeping the underlying requirement substantially the same. A scope change adds to or materially changes the requirement itself.

Consider these examples:

Request Likely classification

Replace the homepage hero image Revision Reduce headline size Revision

Replace an approved testimonial Revision

Change the order of existing homepage sections Usually revision

Add a new pricing calculator Scope change

Introduce multilingual functionality Scope change

Add a customer account area Scope change

Reopen an approved homepage after a positioning Potential scope change change

Fix a form that does not meet the agreed specification Agency responsibility

That last example is important.

Not every additional piece of work is scope creep.

If the agency agreed to deliver something and failed to deliver it correctly, fixing it should not suddenly become an “out-of-scope request”.

When is extra work the agency's responsibility?

Suppose the agreed requirement states:

Form submissions must create contacts in HubSpot.

The development team launches the form, but HubSpot submissions fail.

Fixing the integration is not a change request.

It is completing the original scope properly.

The same applies where:

• the agency overlooked a documented requirement;
• implementation does not match an approved design;
• the website contains a defect;
• functionality does not satisfy agreed acceptance criteria;
• a deliverable was accidentally omitted.

Scope control should protect the agency from additional requirements.

It should not be used to charge clients for the agency's own mistakes.

That distinction builds trust and makes legitimate out-of-scope conversations much easier.

3. Use approval gates throughout the website project

Do not treat project approval as something that happens only immediately before launch.

Create approval points at meaningful stages.

For example:

Sitemap approved ↓ Wireframes approved ↓ UI approved ↓ Development completed for UAT ↓ Launch approved

Approval should mean:

This stage is sufficiently agreed for the project to progress.

It should not merely mean:

The client has seen the file.

Once a stage is approved, reopening it may still be possible.

But the agency can assess whether reopening it creates:

• additional design work;
• redevelopment;
• new QA;
• additional cost;
• timeline changes.

This is particularly important when design is already in development.

A homepage redesign that takes four hours in Figma may create much more than four hours of downstream work if the approved version has already been built.

4. Centralise client feedback

A project can have ten stakeholders.

It should not have ten independent instruction channels.

Without control, feedback may arrive through:

• Figma;
• email;
• WhatsApp;
• Slack;
• project-management software;
• calls;
• direct messages to designers or developers.

Now the team has to determine which instruction is current, which one conflicts with another and who actually has approval authority.

A stronger model is:

• one nominated client contact;
• one agreed feedback system;
• consolidated feedback;
• clearly defined approval authority.

Current agency project-management guidance identifies scattered communication alongside scope creep and profitability leakage as recurring problems in client delivery.

Multiple stakeholders are not the problem

The founder, sales director and marketing manager may all need input.

The problem appears when all three independently instruct the production team.

Instead, ask the client to consolidate feedback before submitting the final instruction.

That also makes a “revision round” measurable.

5. What should you do when the client asks for something new?

Do not immediately say yes.

Do not immediately say no either.

Assess the request.

A simple Four-Impact Test works well for website projects.

1. Work

Does the request require additional:

• strategy;
• design;
• development;
• content;
• migration;
• PM;
• QA?

2. Cost

Does the project now require additional internal or external resource?

3. Time

Does it affect:

• the current milestone;
• development sequence;
• QA;
• launch date?

4. Dependencies

Does the change affect:

• approved work;
• other pages;
• integrations;
• content;
• SEO;
• another supplier;
• client teams?

Once you know the impact, decide what happens.

Atlassian's current change-control guidance recommends essentially this sequence: capture the request, assess schedule and resource implications, then approve, reject, defer or swap the change before updating the project plan.

Use Add, Swap or Defer instead of automatically saying no

Not every additional request needs to become an argument about fees.

For meaningful new scope, give the client clear options.

Option A: Add it

Include the new requirement now.

Adjust:

• price;
• timeline;
• project plan.

Option B: Swap it

Include the new requirement but remove something else of comparable delivery impact.

This is particularly useful when the client has a fixed budget or hard deadline.

Option C: Defer it

Keep the existing release intact and move the idea into:

• phase two;
• post-launch improvements;
• maintenance;
• future roadmap.

This turns:

“No, that's out of scope.”

into:

“We can absolutely do it. Here are the three ways we can handle it.”

That is better project management and usually a better client experience.

What should a website change request include?

Change control does not need to mean a five-page corporate document.

For most agency website projects, a change request only needs to answer:

Requested change

What does the client want to change?

Reason

Why is the change required?

Delivery impact

What additional work is involved?

Cost impact

What additional fee applies?

Timeline impact

Which dates or milestones change?

Approval

Who authorised it?

Then update the agreed scope before work begins.

A simple process people actually follow is more useful than an elaborate process everyone bypasses.

PMI's change-control guidance similarly emphasises assessing cost and schedule impacts and obtaining approval while cautioning against processes so bureaucratic that stakeholders work around them.

A practical website scope-change example

Imagine an agency has sold a marketing website containing:

• 12 pages;
• six unique templates;
• case-study CMS;
• HubSpot contact forms;
• two UI revision rounds.

During development, the client asks:

“Could we add a quick calculator that asks visitors five questions and recommends the right service?”

It sounds like one new section.

But the agency assesses the impact.

UX/design

• question flow;
• calculator interface;
• results state;
• error/empty states;
• mobile behaviour.

Content

• five questions;
• available answers;
• recommendation rules;
• result copy.

Development

• calculation logic;
• state handling;
• responsive implementation.

QA

• different answer combinations;
• browser/device testing;
• result validation.

The agency estimates that the request requires additional work and will extend the current delivery schedule.

Now the client can:

• approve the additional fee and timeline;
• swap another deliverable;
• defer the calculator until post-launch;
• cancel the request.

The project has changed.

But the scope has not crept.

The change was visible before the work happened.

Should you charge for every small out-of-scope request?

No.

Treating every two-minute adjustment as a formal commercial negotiation can be just as damaging as never controlling scope.

Sometimes absorbing a small request makes sense.

For example:

• the work is genuinely trivial;
• the relationship warrants some goodwill;
• the agency created inconvenience elsewhere;
• administering the change would cost more than doing it;
• the adjustment is strategically worthwhile.

The important question is whether the agency is choosing to absorb the work.

Not whether it is quietly doing it because nobody wants to discuss scope.

A useful principle is:

Goodwill should be deliberate, not accidental.

You can even preserve the boundary while absorbing the request:

“That's technically outside the agreed scope, but it's a small adjustment, so we're happy to include it this time without changing the fee.”

The client receives goodwill.

The project boundary remains visible.

How do you tell a client something will cost extra?

Avoid framing it as confrontation.

Do not say:

“You keep asking for things outside scope.”

Explain the change objectively.

For example:

The calculator is a new requirement beyond the approved website scope. We can include it in this phase. It will require additional UX, development and QA, which adds £X to the project and moves the expected launch by approximately one week.

The conversation becomes:

request → consequence → decision

rather than:

client vs agency.

You are not rejecting the idea.

You are showing what accepting it changes.

That is often the easiest way to protect both the relationship and the project economics.

A scope change should affect the timeline as well as the fee

Agencies sometimes remember to charge for additional work but forget to change the deadline.

That can still create a delivery problem.

Suppose your team has capacity for:

100 hours before launch.

The client adds work requiring another:

20 hours.

Something must now happen:

• the deadline moves;
• additional capacity is added;
• another deliverable is removed;
• or the new requirement is deferred.

The schedule does not magically remain unchanged because the client has agreed to pay more.

For every material change, assess:

What happens to cost?

and:

What happens to time?

Both matter.

How does scope creep affect website profitability?

Scope creep creates additional delivery cost without equivalent additional revenue.

Suppose an agency sells a website for £12,000.

Estimated direct delivery cost:

£7,000

Expected project gross profit before wider overhead:

£5,000

Now additional unpriced work adds:

£1,500 of design, development and project-management cost.

The client fee remains:

£12,000

Actual delivery cost becomes:

£8,500

Gross profit falls to:

£3,500

The agency has not “only done a few extras”.

It has materially changed the economics of the project.

This is why scope control belongs in conversations about agency profitability, not merely project administration.

How should scope be controlled with freelancers or white-label partners?

Scope control becomes even more important when delivery passes through several people.

Imagine:

Client ↓ Account manager ↓ Agency PM ↓ White-label developer

The client asks the account manager:

“Can we just add another filter?”

The account manager says:

“That should be fine.”

The request reaches development.

The partner builds it.

Nobody has checked:

• supplier cost;
• internal PM time;
• development schedule;
• QA impact;
• client price.

Scope creep has now happened inside the agency's own delivery chain.

Using an external development partner does not transfer scope-management responsibility away from the agency.

The agency still needs to control:

• what has been approved;
• which requirements are current;
• whether additional work is commercially authorised;
• whether the external partner's timeline needs updating.

A white-label delivery partner can price and schedule the work they have been given.

The agency still owns the commercial boundary with its client.

Common causes of website scope creep

Cause What happens Better control

Vague requirements Everyone interprets features Define expected behaviour differently

Undefined revisions Feedback continues indefinitely Set revision rounds and boundaries

Late stakeholders Approved work gets reopened Identify approvers early

Scattered feedback Team receives conflicting Centralise feedback instructions

Missing content Layout repeatedly changes Define content responsibility

Informal approvals Nobody knows what was actually Record approvals signed off Direct developer Extras bypass commercial review Route changes through PM requests

Unknown integrations Technical complexity appears late Investigate before fixed scope

No change process Small requests automatically Assess first become work

Agency delivery Agency labels rework as scope Own and fix agreed mistake creep requirements

What should agencies avoid?

Don't rely on the contract alone

A good contract matters.

But it does not manage the project every day.

You still need an operational process for:

• feedback;
• approvals;
• revisions;
• changes.

Don't do the work and negotiate afterwards

Once the calculator, new page or integration is already built, your negotiating position becomes much weaker.

Discuss the impact before implementation.

Don't let individual developers approve scope

A developer saying:

“Yeah, that's probably easy.”

is not the same thing as the agency approving additional project scope.

Technical effort, QA, PM, timeline and commercial impact still need to be considered.

Don't treat every client idea as a problem

Clients will discover new ideas while seeing the website take shape.

That is normal.

A good process allows change.

It simply makes the consequences of that change explicit.

Don't create so much bureaucracy that nobody uses the process

The change-control process should be proportionate to the project.

A £5,000 marketing website does not need the same governance as a complex enterprise platform.

Keep the process lightweight enough to use consistently.

When normal scope-control advice needs adjusting

Some projects require stronger controls than others.

The client is rebranding at the same time

Messaging, typography and visual direction may still be moving.

Document stronger assumptions and approval gates.

Content isn't finished

Changing content can repeatedly alter page layouts and development.

Make content availability a clear dependency.

There are several senior stakeholders

Define one person who consolidates feedback and one person who gives final approval.

The website involves complex ecommerce

Product rules, fulfilment requirements and operational edge cases may emerge as the project develops.

Use deeper discovery and more formal change management.

The project depends on an undocumented integration

Technical investigation may need to happen before a fixed implementation price can safely be agreed.

Legal or regulatory teams approve the site

Allow for defined review stages rather than treating late compliance feedback as ordinary design revisions.

The amount of scope control should reflect the amount of uncertainty.

Website Scope Control Checklist

Before delivery starts, check:

Scope

• Is the current scope written down?
• Are deliverables clear?
• Are exclusions clear?
• Are important assumptions documented?

Client management

• Is there one primary client contact?
• Is final approval authority known?
• Is feedback consolidated?
• Is there one agreed feedback channel?

Revisions

• Are revision rounds defined?
• Does everyone understand revision vs new requirement?
• Are previously approved stages treated as approved?

Changes

• Is every new material request assessed before work begins?
• Is cost impact considered?
• Is timeline impact considered?
• Are dependencies considered?
• Is the change formally approved?

Delivery

• Can designers/developers identify the latest approved scope?
• Are external partners informed when scope changes?
• Are direct client requests routed through the appropriate project owner?

If several of those answers are “no”, scope creep is not simply a client behaviour problem.

It is a process problem.

What should your agency do?

Do not build your website-delivery process around the assumption that clients will never change their minds.

They will.

And sometimes they should.

A client may discover a better idea after seeing the wireframe. New commercial information may appear. A stakeholder may reveal a legitimate requirement that nobody knew about during discovery.

The objective is not to freeze the project regardless of what you learn.

It is to control what happens next.

For every meaningful request:

Request → Assess → Decide → Approve → Update → Build

Assess its impact on:

• work;
• cost;
• time;
• dependencies.

Then:

• add it;
• swap it;
• defer it;
• or decline it.

Change isn't the problem. Unpriced, unapproved change is.

If your agency uses external delivery capacity, that process matters even more. Oncreation works with agencies as a behind-the-scenes website delivery partner against an agreed scope across strategy, design, development, QA and launch, while additional requirements can be assessed separately before they enter delivery.

Sources

Teamwork — Scope Creep in Agency Project Management

Used for the current agency-specific definition of scope creep and its effects on cost, timeline, resources and profitability.

Teamwork — Client Project Management

Used for current agency guidance on recurring client-delivery problems including profitability leakage, scope creep and scattered communication.

Atlassian — Scope Creep in Project Management

Used for the current change-control sequence of capturing requests, assessing impact, making trade-offs, recording decisions and updating the project plan.

Project Management Institute — Scope Change Control

Used for the distinction between normal project change and uncontrolled change, including impact assessment, approval and scope-baseline updates.

Project Management Institute — Preventing Scope Creep

Used for practitioner guidance on how incomplete requirements and additional stakeholder ideas contribute to scope expansion during website and technology projects.