Nobody on a WordPress project ever asks for a lot more. They ask for “one small thing”. A second contact form. A page for the new service. Could the blog have categories after all. Could we just try the header in blue. Each request takes an hour or two, each one feels too minor to argue about, and by the end of the project the agency has built a different site from the one it priced.
Scope creep is rarely one big change. It is twenty small ones that nobody wrote down. The good news is that most of it can be prevented with dull, repeatable habits rather than difficult conversations, and the conversations that remain get easier once the habits are in place.
Where creep comes from on WordPress projects
WordPress makes some kinds of creep especially likely, because so much looks easy from the outside. Knowing the usual sources helps you write a scope that closes them off before they open.
- “Can’t you just add a plugin?” Clients see plugins as free features. Each one needs choosing, configuring, styling to match the theme, testing with everything else and updating for the life of the site.
- Content. The proposal says “up to eight pages”. The client sends eleven, plus thirty blog posts from the old site that need moving, plus images that need resizing.
- Design rounds. “Two rounds of revisions” means nothing if a round is not defined. Is a round one list of feedback, or every email sent in a week?
- Integrations. Booking tools, CRMs, newsletters and payment gateways each bring their own accounts, API keys and surprises.
- Post-launch drift. The site is live, but the project never formally closed, so requests keep arriving under the project budget.
- The new stakeholder. Someone senior joins the project late and has opinions about decisions that were already approved.
Write a scope that answers the questions before they are asked
A good scope document is not long. It is specific. The test is simple: if the client asked “is X included?”, could someone who has never met them answer from the document alone?
For a WordPress build, make sure yours covers:
- Pages and templates. List the pages by name. Separate unique templates from pages that reuse one, because a new template is real work and a new page on an existing template usually is not.
- Content responsibility. Who writes the text, who supplies images, the deadline for supplying them, and whether content migration from an old site is included and up to what amount.
- Functionality. Each feature in one line: “Contact form sending to one email address”, “Event listing with date and location, no ticketing”.
- Plugins and third-party services. Which premium plugins are included, and who owns their licences after launch.
- Revisions. What a round is, how many there are, and what happens after the last one.
- Browsers and devices. Which you test on, stated plainly.
- Exclusions. A short “not included” list. This is the part clients read most carefully, and it prevents the most arguments.
- The finish line. What “launched” means, how long post-launch fixes are covered, and when the project closes.
The exclusions list deserves extra thought. Write down the things clients commonly assume: copywriting, SEO beyond basic setup, logo design, email setup, ongoing hosting management. It is far easier to say “that’s on the not-included list, but we can quote it” than to explain an assumption after the fact.
A change request process that does not feel like bureaucracy
Clients do not mind a process if it is fast and polite. What annoys them is a surprise invoice. The aim is to make every change visible at the moment it is requested, not at billing time.
A workable process looks like this:
- The request arrives, by any channel.
- You decide whether it is inside scope, a small change, or a new piece of work. Do this quickly, even if the estimate comes later.
- You reply in writing with what it would involve, how it affects the timeline, and the cost or hours.
- The client approves in writing, even a one-word reply, before work starts.
- You log it, so the running total of approved changes is always visible.
Step two is where most agencies slip. If you sort requests the same way every time, the decision stops feeling personal. A clear routine for sorting incoming requests helps here; see our piece on triaging client requests into urgent, routine and change.
Wording that keeps the relationship intact
Saying “that’s out of scope” bluntly can sound like refusing to help. The trick is to say yes to the idea and be clear about the terms.
When the request is reasonable but not included
“Good idea, and it would suit the site. It isn’t part of the original scope, so I’ve put together what it would involve: [short description], adding about [time] to the schedule. If you’re happy to go ahead, reply to confirm and we’ll fit it in. Or we can keep it for a second phase after launch.”
When several small changes have piled up
“Quick update: alongside the main build, we’ve handled a few extra requests: [list]. We were glad to do these, and so far we haven’t charged for them. Any further additions we’ll need to quote separately, so I’ll send you a short estimate for each from now on.”
This is honest about the goodwill you have already given, and it resets expectations without accusing anyone.
When a late stakeholder wants to reopen approved work
“Happy to take [name]’s feedback on board. The [section] design was approved on [date], and the build is based on it. We can certainly revise it; it would be handled as a change, and I’ll send an estimate. Would you like me to do that, or keep the approved version for launch?”
Giving the client a clear choice between two acceptable options keeps you out of the role of the obstacle.
Small requests: decide once, then stay consistent
Not every extra deserves a quote. Writing an estimate for a five-minute text change wastes everyone’s time. The problem is not doing small favours; it is doing them inconsistently, so the client never knows which requests will be free and which will be billed.
One approach is a small change allowance written into the scope: a fixed number of hours for minor adjustments, with a note in your updates showing how much is used. Clients like it because they can see the goodwill. You like it because it has a ceiling.
Whatever you choose, keep a record. Even unbilled changes go in the log. If the project ever runs late, that log is how you explain why.
Creep after launch, on retainers and care plans
Scope creep does not stop at launch. On a maintenance retainer it looks different: the plan covers updates, backups and small edits, and “small edits” slowly expands to cover new landing pages, plugin research and redesigning the footer.
Define what a small edit is, in the same terms you would use for a build. A useful rule of thumb is that changing existing content is an edit, while adding something new is a project. Your maintenance agreement should say this plainly; our article on the clauses a maintenance agreement needs covers the wording in more depth.
Also watch for “while you’re in there” requests. A client who knows you are updating plugins on Thursday may ask you to fix something unrelated at the same time. Fine, but log it and count it.
If you work with a development partner
When part of the build is outsourced, scope creep has two edges. Your client can creep on you, and if your brief to the partner was vague, the work can drift on their side too. Every change the client approves needs to reach the partner in writing, with the same clarity you would want if you were doing the work yourself.
Two habits help:
- One channel for changes. Approved changes go to the partner through a single place, not scattered across emails and chat. That way nothing gets built from a half-approved message.
- A brief that defines done. If your brief describes the end state rather than a list of instructions, the partner can tell when a request goes beyond it and flag it to you. Our guide to writing a brief a remote developer can work from walks through this.
A partner should come back to you, not to your client, when something looks like extra work. That keeps you in control of the conversation and the margin.
When to absorb a change and move on
Sometimes the right call is to do the extra work without charging. Perhaps your scope genuinely missed something obvious, or the client has given you three other projects. That is a business decision, and a fair one, as long as you make it on purpose.
Signs it is worth absorbing:
- The gap was your mistake, such as a requirement you heard in a meeting and forgot to write down.
- The cost is small and the relationship is valuable.
- Charging would cost more in goodwill than the work is worth.
Even then, tell the client you have done it at no charge. Unspoken goodwill is invisible goodwill.
A short checklist for your next WordPress project
- Pages and templates listed by name
- Content owner and deadline stated
- Premium plugins and licence ownership noted
- Revision round defined
- “Not included” list written
- Change request route agreed with the client at kickoff
- Change log started on day one
- Project close date and post-launch fix period stated
For the bigger picture on staffing, partners and how outsourced work fits around a project like this, see our guide to outsourcing WordPress work as an agency. And if scope creep keeps happening because your team simply has no room for the extra requests, our page on extra development capacity for busy agencies describes how we take on overflow without stepping into your client conversations.
Next in this series: Website Handoff Checklist for Agencies
