Scope creep starts at the brief, not the revision

The standard narrative about scope creep is that it happens during revision rounds: the client keeps adding things, the contractor keeps absorbing them, and eventually the project is twice the work for the same budget. That's accurate, but it's describing the symptom. The disease is usually in the brief.

We've tracked the pattern across our projects and the ones that ran over time or budget almost always shared one characteristic: the brief was treated as a starting point rather than a commitment. What follows is a list of signals we now treat as early warnings.

The "we'll figure it out as we go" brief

Some clients describe a vague direction and expect the project to clarify itself through iteration. This works for some types of product work. It does not work for scoped design and development projects with a fixed price.

When a brief uses phrases like "flexible on the details" or "open to direction," it usually means the person writing it hasn't made the decisions that shape the scope yet. Those decisions don't disappear — they get made during the project, usually after work has already been done in a different direction.

We now ask, before starting: what would make this project a success? If the answer is specific ("200 signups in the first month," "a site that replaces our current one before August"), we're dealing with a real brief. If the answer is vague ("something we're proud of," "a professional-looking site"), we ask more questions before putting pen to paper.

Multiple stakeholders with unaligned expectations

This is the most reliably expensive pattern we've encountered. The initial conversation happens with one person. Halfway through the project, a co-founder or department head sees the work and has entirely different requirements. The client apologises and explains that everyone needs to be happy with it.

The problem isn't that multiple people have opinions — that's normal. The problem is that the opinions weren't reconciled before the project started. Reconciling them during a project means undoing work.

We now ask in every intake: who else has approval authority on this project? If the answer isn't "just me," we either get everyone in the same briefing conversation or we build explicit approval checkpoints with all stakeholders into the contract.

The brief that treats content as a detail

Design and content are not independent. The layout of a page depends on how much text will be in it, how many items are in a list, what the headings say, whether images exist and what dimensions they are. A design built without content is built on assumptions — and those assumptions fail the moment real content arrives.

When a client says "we'll add the copy later," what they usually mean is that the copy hasn't been written yet and they're hoping the design process will happen in parallel. It won't, or if it does, it will produce a design that needs to be reworked when the copy arrives.

We now either require a content outline before designing, or we explicitly include a content skeleton phase in the project and price it accordingly.

The brief that expands when shown work

Some clients don't know what they want until they see what they don't want. This isn't a character flaw — it's how a lot of people process visual decisions. The problem is that "I know it when I see it" doesn't translate to a predictable scope.

The signal is usually in how the client responds to references or examples. If every reference produces a new requirement ("and also something like this, but also this part of this other one"), the brief isn't stable yet. Proceeding with an unstable brief means the first design round is really just another brief-gathering exercise — at your own cost.

The fix: slow down the beginning. Spend more time on the brief. A brief that takes two weeks to finalise saves four weeks of revision later.

What a reliable brief looks like

It answers: what is the site for, who is it for, what should a visitor do when they arrive, and what does success look like in measurable terms. It lists every page or section. It specifies what content exists and what needs to be created. It names who approves the work and how many revision rounds are included.

It doesn't need to be long. The best briefs we've received have been two or three pages of plain text. The worst have been twenty-page decks full of inspiration images and no decisions.

---

We now send our own brief template to every new client before starting work. It's a short document with specific questions. The answers to those questions determine the scope. If the answers change after the project starts, the scope changes and the contract is updated. No surprises, no absorbed extras, no awkward conversation at the end about why the budget ran over.

If you're about to start a project and haven't filled in a brief like this, do it before the first work session. The hour it takes will save considerably more on the other end.