The final week before launch has a strange energy. The site is real now, the client is finally clicking around it properly, and suddenly they have ideas. Lots of them. Each one is small. None of them were in the brief.
Saying yes to all of them pushes the launch back and gives your QA no time to settle. Saying no to all of them sours a relationship you've spent months building. The answer is a clear process that makes the decision easy for both of you.
Agree a freeze date up front
Put a content and feature freeze in the project plan from day one: a date after which only fixes go in before launch. Clients accept this easily at the start of a project. They push back on it hard if you introduce it in launch week.
Mention the freeze in the kickoff call and again in the staging review email. When it arrives, it's a milestone everyone expected, not a rule you invented under pressure.
Separate fixes from changes
A fix is something that doesn't match what was agreed: a broken link, a typo, a section that looks different from the approved design. A change is something new. Fixes go in before launch. Changes go on a list.
Fixes: Before Launch
- A link that goes to the wrong page
- A typo in the agreed copy
- A section that doesn't match the approved design
- A form that doesn't submit
Changes: After Launch
- A new section on the about page
- Rewriting the hero headline
- Swapping the photography style
- Adding a page that wasn't scoped
Make “after launch” a real place
“Not now” only works if it doesn't mean “never”. Keep a shared post-launch list, and offer a short phase-two review a couple of weeks after go-live. Most clients are happy to wait once they can see their idea written down with a date next to it.
Hi [Name],
Love this idea. Since we're past the freeze for launch on [date], I've added it to the post-launch list so it doesn't hold up go-live.
We'll pick it up in the phase-two review on [date], along with anything else that comes up in the first couple of weeks.
Thanks, [Your name]
Protect your QA window
Every late change resets the clock on testing. A new section needs checking for placeholder copy, links, alt text and how it sits next to the design. If changes keep arriving until the day before launch, your final QA pass is checking a site that keeps moving.
When a change genuinely can't wait
Occasionally a late request isn't a nice-to-have. The client has a legal requirement, a pricing change or an announcement that has to be live on day one. Those need a different conversation, not a flat no.
Be honest about the trade-off. Either the launch date moves to make room for the change and a proper QA pass, or the change goes in and something else comes out. What you shouldn't do is squeeze it in without testing and hope for the best.
Price changes clearly
Clients ask for more when the cost of asking is invisible. If late changes are free, they'll keep arriving. That doesn't mean billing for every typo, but it does mean having a clear line: fixes are included, changes are quoted.
Most clients respect a clear quote far more than a vague “that's a bit out of scope”. It gives them a real decision to make, and often they'll decide the change can wait for phase two after all.
Note every change request in one place, with the date it came in and what was agreed. If the launch slips, you'll know exactly why, and so will the client.
If something does go in late, run another Frank scan on the staging site. Every scan is kept on the project, so you can see exactly what changed between the last review and launch. Get started with Frank →
Keep Launch Week Calm
A clear freeze, a real post-launch list and a final QA pass on a site that's stopped moving.
