Round one was supposed to be structure and content. By the third day it also included a new hero animation, a rewritten pricing table, and a request to “just try a dark mode toggle while you’re in there.” Nobody added scope on purpose. Every single ask, in isolation, sounded reasonable. The round that was supposed to take two days is now on day nine, and nobody can point to the moment it stopped being round one.
That’s scope creep, and it’s a website-review-specific version of a problem old enough to have sunk a $560 million airport project. Here’s how to keep it out of your revision rounds without turning into the founder who says no to everything.
What does scope creep actually look like in a website revision round?
It looks like a “yes” to something small, repeated enough times that the round never closes. Scope creep is formally defined as “continuous or uncontrolled growth in a project’s scope, generally experienced after the project begins” — and critically, it tends to enter “as small, simple, and easy to implement changes,” according to the Wikipedia entry synthesizing standard project-management definitions. No single addition looks like the problem. The problem is that a website revision round has no natural stopping point unless someone draws one — so every “while we’re at it” gets absorbed into whatever round is already open, and the round grows to match however long everyone keeps having ideas.
The Denver International Airport’s automated baggage system is the textbook version of the same mechanic at a much larger scale. The original scope covered one concourse for one airline; once other airlines were consulted mid-project, they required “adding ski equipment racks, different handling for oversized luggage, and separate maintenance tracks for broken carts” — changes that forced “major redesign on portions of the project, some of which had already been completed,” according to Wrike’s project-management case study on the failure. The project opened 16 months late and $560 million over budget. Nobody added the whole airport’s worth of scope in one meeting — it accumulated, one reasonable-sounding change at a time, exactly like a revision round does.
Why does scope creep sneak into a review round so easily?
Because a revision round doesn’t have a hard edge — it has whatever’s still open — and every new idea shows up looking like it belongs to whatever’s still open. British historian C. Northcote Parkinson’s famous observation, first published in a 1955 essay, was that “work expands so as to fill the time available for its completion” — as documented on the topic’s standard reference entry. A website revision round is a small, live example: as long as the round is still open, there’s always room for one more thing, because “open” doesn’t come with a boundary of its own. The round doesn’t expand because anyone is being unreasonable. It expands because nothing marked where it was supposed to stop.
This is worse for async feedback than for a live call, ironically. On a call, someone has to say a new idea out loud, and there’s a social cost to derailing the meeting with it. In a written comment thread, adding “one more thing” costs nothing — you just type it where you were already typing. That’s a real advantage of async review for everything else (nobody has to interrupt anyone to raise something), but it also removes the one friction point that used to make people think twice before expanding scope mid-round.
How do you tell a scope-creep request from a legitimate revision?
Check it against what the round was actually supposed to cover — not against whether it’s a good idea. Most scope-creep requests are good ideas. That’s exactly why they’re dangerous: a bad idea gets rejected on its merits, but a good idea that wasn’t part of the plan gets accepted on its merits too, and merit was never the question. The question is whether it was part of what this round was supposed to fix.
The professional version of this check is called change control — the Association for Project Management defines it as “the process through which all requests to change the approved baseline are captured, evaluated and then approved or declined.” A founder-scale website review doesn’t need a change control board. It needs the same two questions, asked in a sentence instead of a form: Was this in the brief or the last approved list? If not, does it need to happen this week, or can it happen next round? If it wasn’t in the plan and it can wait, it’s scope creep by definition — not because it’s a bad idea, but because “good idea, wrong round” is a real, separate category from “bug” or “revision.”
How do you keep new ideas from blending into the round already in motion?
Give every new idea somewhere to land that isn’t the current round — a parking place, not a rejection. The instinct to reject scope creep outright backfires, because most new ideas aren’t wrong, they’re just early. What actually works is capturing the idea somewhere visible and moving on, rather than either acting on it immediately or losing it entirely.
This is the same mechanic David Allen’s Getting Things Done methodology relies on for any incoming idea, not just project work: capture it into “the appropriate parking place” the moment it arrives, rather than deciding on the spot whether to act on it — as Allen’s own organization describes the habit. Applied to a website revision round, that means: the moment “let’s also try a dark mode toggle” shows up, it goes on a visibly separate list — a next round tag, a parked-ideas doc, anything that isn’t the open thread for round one. Nobody has to argue about whether it’s a good idea in the moment. It just isn’t this round’s idea.
What do you do when someone insists a new idea can’t wait?
Ask what specifically breaks if it waits one round — and if the honest answer is “nothing,” that’s your answer. Urgency claims are usually sincere and usually wrong, because “I thought of it now” and “it needs to ship now” feel identical in the moment and aren’t the same thing. Researchers Meng Zhu, Yang Yang, and Christopher Hsee found something similar holds even in controlled experiments: people are “more likely to perform unimportant tasks (i.e., tasks with objectively lower payoffs) over important tasks” whenever the unimportant task merely feels time-sensitive, a pattern they named the mere urgency effect in the Journal of Consumer Research. Feeling urgent and being urgent are two different signals, and most people’s gut reaction can’t tell them apart — which is exactly why “this can’t wait” needs a check beyond how strongly someone feels it.
A genuine blocker — a broken checkout flow, a legal disclaimer that has to be live before launch — fails the “what breaks if it waits” test loudly: something visible breaks if it waits. A preference dressed up as urgency fails it quietly: nothing breaks, it just feels good to add now instead of next week.
Occasionally the answer really is “this can’t wait” — a legitimate blocker discovered mid-round is not scope creep, it’s a missed requirement, and it deserves to jump the queue. The test isn’t a way to say no to everything; it’s a way to make the “does this actually need to happen now” question answerable by both people looking at the same page, instead of decided by whoever asked most recently or most insistently.
How does Simpl_Markup keep an approved round from quietly reopening?
Simpl_Markup marks a project approved once every open comment on it is resolved — a specific action a team member clicks deliberately, not a status that just happens when nobody’s watching. Every comment is also tied to the exact page state it was raised on: the URL, viewport, scroll position, and element it was pinned to at the moment someone dropped it. That means a new idea after approval can’t quietly rewrite what the round already decided — it has to become a new pin, on the current page state, visibly separate from whatever’s already resolved. The old round stays exactly as decided; the new idea starts its own visible thread instead of blending into it.
That’s a structurally different shape than a flat Slack thread of screenshots and arrows, where a new ask and an already-resolved one both just scroll past together with nothing to tell them apart — Simpl_Markup’s comparison against that workflow covers why that lack of separation is the default, not an exception. It’s also different from a bug tracker built for engineering teams, where every incoming item gets triaged into the same backlog regardless of which round it belongs to — Simpl_Markup’s comparison with BugHerd covers that distinction if you’re picking between the two.
None of this decides for you whether a new idea is worth doing. What it does is make “this is a new idea, not part of the round we already agreed to” a visible, checkable fact instead of something that gets absorbed into the round by default because nobody drew the line. The round that was supposed to take two days stays a two-day round — and the dark mode toggle gets a real conversation next week, instead of a silent yes it never should have gotten this week.