How a marketing site gets scoped so the date survives

A website project scope that survives its date is a list of pages and the states of those pages, with the date attached to that list. Phases called discovery, design, and build describe a mood. They do not say what will exist on launch day, so every new idea looks like it fits. Scope the pages. Then you can see what a change does to the date.

Write the scope after you know who the site is for and what action it should earn. If that one-pager does not exist yet, make it before you argue about timelines. A scope without an audience is a menu. Bring the one-pager to an intro call with Hanabi when you want to know whether the list is real enough to price. The call should settle fit and the shape of the work. It should not turn into a free design session.

Pages, not phases

List every URL you expect to publish. For a young company that is often a short set: home, product or service, proof, about, and a way to start a conversation. Write the name of the page and one sentence for its job.

Under each page, list the states you will actually design and build. A marketing page is not one picture. It has at least a few of these:

• The first screen, with the offer and the action.
• The rest of the page on a phone and on a wide screen.
• The empty or loading look, if something comes from a CMS or a shop.
• The confirmation state after a form or a purchase.
• The error, if a form can fail or a product can be unavailable.

A shop adds catalog, product, cart, and checkout states. A content site adds a draft and a published article. If a state is not listed, it is not in the date. "We'll handle edge cases in QA" is how the last week fills up with decisions that belonged in the scope.

Attach non-page work the same way, as items with a done definition. Redirects from old URLs. Analytics that record the intro. Basic metadata, including a descriptive title on each page. Google's title-link guidance is a useful done definition here: every page has a title element, the title is descriptive, and it is not a vague label such as "Home" repeated across the site. That is a checklist item, not a phase called SEO.

What "done" means for speed

Put a performance bar in the scope if you care about it on launch day. Otherwise it arrives as a surprise argument. Google's Core Web Vitals are a clear public bar. Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint under 200 milliseconds, and Cumulative Layout Shift under 0.1. You do not need a custom scoring system. You need to say that the agreed pages should meet that bar on a normal phone connection before the date counts as met.

Name who checks. A studio can measure. A founder should know what "fast enough" means so the review does not become a feeling. If a campaign video is in the scope, say so, and accept what it does to the loading measure, or agree that the video waits until after launch. Silent assumptions are schedule items in disguise.

Accessibility basics belong in the same kind of line: text you can read, controls you can reach, images that have a text alternative when they carry meaning. You are not certifying a legal audit unless the scope says you are. You are preventing a launch that only works for the person who designed it on a laptop.

What a change does to the date

Once the list is agreed, a change is a change to the list. Adding a page adds the design, the build, the states, and the review of that page. The date moves by that amount, or something else leaves the list. Adding a state to an existing page, such as a second language, a logged-in view, or a new form with its own confirmation, is the same kind of change. It is smaller than a new site and larger than a wording fix.

Treat these as in-scope, and keep the date:

• Rewording inside an agreed section.
• Swapping an image for another image of the same kind.
• Adjusting type, space, and color within the system you already chose.
• Fixing a bug that breaks an agreed state.

Treat these as a change request:

• A new page, a new audience, or a new offer in the hero.
• A new integration, such as a shop, a CMS, or a booking tool you had not named.
• A new state: accounts, search, a blog, a second currency.
• A new round of design after the agreed direction was accepted.

Write the consequence in the scope in one paragraph, before the project starts. When the request arrives, you should not be inventing the policy in the thread. The date survives because the rule was dull and visible. Projects slip when every addition is described as "small" and none of them are allowed to move the calendar or the list.

A founder can still change their mind. The scope's job is to make the cost of that change obvious while there is still time to choose. Sometimes the right choice is to move the date. Sometimes it is to ship the agreed list and schedule the new page next. Both are honest. Pretending the list grew and the date did not is how launch week becomes a pile of half-finished states.

What does not belong in the first scope

Leave out work you hope to "get to" if there is time. Hope is not a page. If the blog might matter, put it in a later list with no date, or give it a date and remove something else. A scope with optional pages trains everyone to assume the options are included.

Leave out redesigning the product itself if this project is a marketing site. Link to the product. Do not quietly pull the application into the website project because the navigation mentioned it. A product interface has its own states: empty, error, success, and the one workflow. Those states are a different scope.

Leave out a research program you will not use. A few interviews can be a line item if they will change the page. A standing workshop with no decision at the end will eat the date and produce notes. Scope the decision, not the meeting.

Name what the client will provide, and when. Copy, access to the current site, brand files, and a single approver. Missing access is a change to the date even when the page list stays still. Put the dates for those inputs next to the page list so a delay is visible as a delay.

Agree, then hold the list

Review the scope by reading the page names out loud and asking, for each one, what "done" looks like in a browser. If the answer is "you'll know it when you see it," the state is not scoped. Add the state or cut the promise.

Send the list in writing. A verbal "sounds good" does not hold a date. When a new idea appears, point at the paragraph you already agreed: it joins the list and the date moves, or it waits. That is the whole discipline.

The list gets easier to write if the brief was short and specific. If you still need that one-pager, read how to brief a studio for a marketing site. Audience, action, references, and constraints are the facts a page list is built from.