Week one rarely goes wrong because the developer works slowly. It goes wrong because three people carry three different versions of the job. The client adds a page on Monday night. The marketer adds a pixel and one more field on Tuesday. The designer sends a state nobody priced. By Wednesday, the developer is guessing. The date in the proposal no longer matches the work. Nobody planned to create a mess. Nobody wrote the freeze.
A freelancer feels this as a schedule that keeps moving and a client who says, “that was obvious.” An agency feels it in a different way. On the client call, the developer looks unreliable, but the real gap sits inside the agency. The person who sold the work and the person who builds it never shared one list. The fix is not a longer kickoff. The fix is a short written freeze before build starts, plus a plain change path for anything that arrives later.
1. What a written freeze actually contains
Keep it short. A tired person should be able to read it without a call. Write one outcome in the client’s words. List the pages or flows that are in. List the pages or flows that are out. Add the checks you will use to accept the work. Add the date that belongs to this list, not to a hopeful guess. If this does not fit on one page, you do not have a freeze. You have a backlog dressed up as a promise.
Name the platform and the exact place where the result has to land. A new contact form is not finished if nobody tied it to an inbox or a CRM card. That is a second project hiding inside the first one. The usual attachments around outcome, access, and acceptance are covered in what to attach before development starts. This article is about a different moment: the point where you stop adding lines and call the list closed.
Put the freeze in one file the next person can open without a retelling. A voice note, twenty chat messages, and a slide called “scope” are three different memories. Pick one file. Put a date on it. If the file changes, the date changes too. The developer should be able to start Monday from that file alone.
2. The out-of-scope list has to be as specific as the in-scope list
“Everything else” is not a boundary. People hear it as “we will discuss it later.” Write down the requests you already expect. A blog. A second language. A payment step. A redesign of pages outside the campaign. A new report. A move to another host. Each item can become a fair next project. None of them should slip into week one because someone said, “while you are there.”
Also write down the decisions nobody is taking yet. If the client has not chosen the offer, the developer does not invent the headline. If the designer has not supplied empty, error, and success states, the developer does not make them up on Friday and call them included. The handoff that prevents that guessing is a separate checklist: what to give a developer so the build is not redone.
If the package is still incomplete, the freeze does one of two things. It waits. Or it marks the missing piece as out of scope until it arrives. Read that out-of-scope list to the client before build starts, not after the first invoice argument. A clear no is kinder than a surprise. It also protects the agency. When the request appears, you can point to a line the client already saw.
3. The change path is the part people skip
A freeze that cannot handle a real change will be ignored by Thursday. Clients do learn things in week one. A field is wrong. A legal line has to move. The path has to exist, and it has to stay boring. One person on the agency or freelancer side is allowed to accept a change. The request goes into the same document as a new line. That line says what moves: the date, the price, or both. Work on that line does not start until the client has seen the move.
Chat is fine for noticing a request. Chat is bad for accepting it. “Sure, quick one” in a thread easily turns into three days, while the original date still sits in the proposal where the client can quote it. If you need one rule people can repeat, use this: if the change is not in the document, it is not in this week. The developer is allowed to keep building the frozen list while the new line waits. That is not stubbornness. That is how week one stays one week.
Watch for the change that pretends to be a bug. “The form should also create an invoice” is not a bug in a contact form. It is a new flow. Treat it as a new line. If you fold it in just to keep the peace, the freeze is gone, and the next request will arrive the same way. A redesign brief fails in the same pattern when the word redesign quietly turns into three projects. That version is covered in how a marketer briefs a redesign without week-one scope chaos. The discipline here is the same, just applied before any build.
4. How week one looks when the freeze holds
Monday starts from the file. The developer can name the outcome, the pages in, and the pages out without asking around. Access already exists for a private place to test, or the freeze says clearly that testing on the live site is a known risk. The first build target is small enough to accept with the checks already written. Nobody spends Monday on “alignment.”
By midweek, new ideas still appear. They go to the one person who can accept a new line. The developer hears about them as a dated addition, or does not hear about them yet. The client sees that yes has a time cost. That conversation is calmer than a Friday argument about why the original list is still unfinished.
On Friday, you accept what the freeze named. You use the checks you wrote, on the private copy if you have one. A failed check points to a line. A new wish becomes a new line with a new date, or it waits. You do not reopen the whole job because a detail feels different in the browser. If the client joins the call, they are looking at the same list you are. The week ends with one shared picture, not with a promise to “clean it up over the weekend.”
When to bring the developer in before the freeze is promised
You can draft the freeze yourself if you know the campaign and the current site. Bring a developer in before you promise the date when the work assumes behavior the site may not have, when there is no private place to test and the client expects edits on the live site, or when the client’s brief is “all of it, quickly.” A developer who sees the list early can tell you which lines are one job and which lines are really three. That conversation costs less on day zero than on day eight.
Services include reading a scope like this and pointing out where the hidden second project sits, so it does not come back as a second invoice. Selected work shows results next to the operation, not as mood. If you write, send the outcome in one sentence, the in list, the out list, and who is allowed to add a line. Leave client passwords out of the first message.