“Hey Phill, Can we make the logo bigger? “
In my talk at WordPress Chiang Mai in June 2025, I covered a popular topic which i’ve had to wrestle with over my 10 years in website development. If you’re involved in any aspect of the delivery, be it project manager, developer, designer or co-ordinator, you will know how a few adjustments can grow indefinitely, if you don’t set clear boundaries.
The Scope Creep Effect
You’ve a had the layouts signed off, all assets are received and your ahead of the timeline when your inbox pings:
“Hey, we’ve just had a customer try and visit our new domain. Could you drop in a simple landing page with our email address while we’re building the project? We just want it to be simple.”
Unless your website build is unusually complex, adding a basic landing page with a logo and contact details is a fairly small task.
The issue isn’t the request itself. It’s that agreeing to work outside the original scope quietly opens a door, one that can affect resources, timelines, and focus in ways that aren’t immediately obvious.
Let’s assume you agree. Here’s a very realistic sequence of follow-ups that many people working on websites will recognise:
Thanks for adding the homepage, the logo is a little small, can you tweak it?
We’ve updated our email address, kindly change it to be [email protected]
Can you add our John from Marketing to the site, so we can add some text to the landing page? .
John from Marketing has installed a plugin which has crashed the site
This sequence may sound slightly cynical, but it’s not unrealistic — particularly when working with active marketing teams.
The key point is this: when you agree to a change that sits outside the agreed scope or timeline, you also become responsible for the lifecycle of that change. Even something that starts as “just a simple request” can quietly disrupt the wider workflow.
It’s Rarely About Bad Intentions
So are these changes accidental or intentional?
In most cases, they’re accidental and especially when you’re working through design and build phases with multiple stakeholders involved.
It’s unrealistic to expect most businesses to have complete clarity on what they want from a website from day one. Iteration is normal. Adjusting layouts, refining content, and tweaking components are all part of finding the right outcome.
The risk increases when communication passes through intermediaries such as agencies collecting feedback and relaying it back to development teams. Each layer adds interpretation, and with it, the potential for assumptions to slip in unnoticed.
Why Website Projects Rarely Prepare Teams for This
It’s dangerous to assume that requirements will arrive clearly defined, or at least settle quickly once work begins. But this is a common occurance among website agencies who do not enforce a water tight planning structure.
In reality, straightforward is rarely how projects unfold. Priorities shift, new information appears, and decisions are often deferred.
When ownership of those decisions isn’t clear, the ambiguity doesn’t disappear, it gets absorbed by the delivery team. Developers and designers end up making judgment calls simply to keep things moving, especially when requests seem small or reasonable in isolation.
The Real Cost Isn’t Extra Features — It’s Lost Clarity
The biggest cost of scope creep isn’t an extra page or a few additional hours of work, it’s the gradual loss of clarity.
As scope expands informally, priorities blur. Teams spend more time context-switching. Decisions take longer. Confidence drops, not because the work is harder, but because the boundaries are less clear.
At that point, even small tasks feel heavier than they should and the project begins to twist and turn into unexpected places, while timelines and resources are being squeezed
How Experienced Teams Keep Projects Grounded
Teams that handle scope well don’t try to eliminate change, they make it visible. They also pre-empt additional change, spot bottlenecks early on, and build “risk” time aside into their project timeline.
They treat scope as a variable, not a promise. They separate “this is a good idea” from “this is a good idea right now.” Assumptions are surfaced early, and trade-offs are discussed openly rather than discovered late.
Most importantly, changes are framed as decisions with consequences, not just tasks to be completed.
Scope Creep Is a Leadership Problem (and That’s Good News)
Scope creep in website projects isn’t a failure of discipline or professionalism. It’s usually a failure of clarity and ownership.
With the right conversations early on, about defining priorities, constraints, and decision-making, these projects can remain flexible without drifting off course. When scope is treated as a shared responsibility, teams move faster, not slower.
Website projects don’t go off the rails because people don’t care. They do so when small decisions aren’t given the weight they deserve.
My Pro tips to reducing Scope Creep
- Define what “Approved” actually means
Not just features, but decisions, sign-offs, and responsibilities. - Write assumptions down early
Nothing is obvious. - Separate ideas from commitments
A good idea doesn’t automatically belong in the current phase. - Treat scope as a variable, not a guarantee
Time, budget, and scope can’t all be fixed at once - Make decision points visible
Avoid “we’ll figure that out later” unless you’re clear who will own it later and the impact it might have - Have a clear process for change in the beginning
Changes shouldn’t feel sneaky or informal. - Limit who can introduce changes
Too many voices creates drift, even when everyone means well. - Pause before saying yes
Don’t agree straight away unless you immediately understand the impact. - Reconfirm priorities when something new appears
Ask what this replaces, not just how it fits in. - Review scope regularly, not just at the start
Small check-ins/reviews prevent big surprises.