The email always starts the same way. “Just a few small additions.” A new page here, a filter there, a login flow nobody mentioned on the first call. On a project we closed this spring, that pattern showed up three separate times before the site had even launched, and each time it looked small enough to wave through. By the third round we sat down and mapped out everything that had actually changed since the kickoff brief. It wasn’t small. It was close to a second project, unpaid and unplanned, and it wasn’t the client being unreasonable. It was our brief not doing its job.
This is the brief template we now hand every new client before a project starts, the six things it has to nail down, and the one rule that would have caught all three of those additions before they turned into a scramble.
Why Most Project Briefs Fail Before Kickoff
A brief written to get a proposal approved is a different document from a brief written to survive a ten-week build. Most briefs we’re handed cover budget and a rough page count, and stop there. They skip the three things that actually cause scope creep: who has final sign-off on design direction, what “done” looks like for each page, and which integrations are assumed versus optional. Leave those three vague, and every reasonable follow-up request starts to look like a small addition instead of what it actually is: new scope.
This is the same gap our design team now walks every new client through before a proposal is signed, not after (redmonk.in/services/design/). It takes an extra thirty minutes at the start. It saves weeks at the end, and it’s the single biggest difference we’ve seen between projects that finish on the date we quoted and ones that slip by a month.
The Six Things Your Brief Should Nail Down
Before you sign a proposal, whether it’s ours or another agency’s, make sure the brief states:
- The exact page and screen count, named individually, not “a homepage and a few inner pages”
- Every third-party integration by name: payments, CRM, booking, email, analytics. “We’ll figure it out later” is exactly where scope hides
- Who has final sign-off on design, and how many rounds of revision that sign-off includes
- What launch actually means: content migration, redirects, and who owns proofreading before go-live
- A stated timeline for client-side deliverables (copy, images, approvals) — most delays we see are client-side, not agency-side
- One line on what happens if something new comes up mid-build
None of these need a lawyer to write. They need one working session before the contract is signed, where someone on the client side and someone on the agency side go through the list out loud and put answers next to each line, instead of assuming the other person will raise it if it matters.
What Happens When Scope Creeps Anyway
It creeps anyway, on almost every project, because a live build surfaces things a written brief never could have predicted. A stakeholder who wasn’t in the kickoff call sees the staging site and has opinions. A competitor launches a feature and suddenly it’s urgent. None of that is bad faith. It’s just how real projects run. The fix isn’t refusing new requests. It’s agreeing upfront on how they get handled.
On the project mentioned above, we now do this: anything outside the signed brief gets logged the day it’s raised, priced separately, and either folded into a follow-up maintenance contract or quoted as a one-off, before any work starts on it. That one habit turned three rounds of “quick addition” into a straightforward conversation about a maintenance contract, instead of a dispute about the final invoice. The client is still with us on an ongoing basis, which tells us the boundary didn’t cost the relationship. It probably saved it.
A Simple Rule We Use With Every New Client Now
If it’s not in the brief, it’s not in the build, until we’ve both agreed on what it costs and when it ships. That one sentence, written into the kickoff email, has done more for our timelines this year than any project management tool we’ve tried.
It works both ways. Clients get a straight answer instead of a vague “let’s see,” and we stop absorbing unbudgeted work in the name of good service. Good service is finishing on the date we promised, not quietly eating the cost of scope nobody signed up for. Prospective clients evaluating an agency should expect a straight answer to this question at the proposal stage, before any money changes hands. If an agency can’t tell you how it handles a mid-project change request, that’s worth asking twice.
Before You Brief Your Next Agency
- Name every page, integration and sign-off before you sign a proposal, for this project or the next one
- Treat a “small addition” as a decision point, not a favour — log it, price it, then decide
- Ask any agency you’re evaluating how they handle scope changes. Their answer tells you more than their portfolio does
Heading into a redesign or a new build and want the brief right before you write it? Book a free consultation at redmonk.in/contact-us and we’ll go through it with you first. If you’re still deciding between a freelancer, an AI builder and an agency, we wrote about that trade-off too: redmonk.in/blog/hire-a-web-designer-in-india-not-an-ai-builder.
