What to have ready before kickoff

Before kickoff, gather the accounts, a rough offer, access to the current site, and the name of the person who can approve. Missing access spends the first week on waiting.

By
A hand pinning string between printed mobile screens on a wall, planning that depends on an approver and on access already being in place.
The wall plan works once someone can approve it and the logins exist. Photograph via Unsplash.

A website project kickoff goes well when four things are already true: someone can approve the work, the offer is written in rough form, the studio can open the current site, and the accounts that matter are in the client's name. Missing access burns the first week. The team spends it waiting on passwords instead of learning the product.

Kickoff is the start of production. It is a poor moment to discover that the domain login lives in a former employee's inbox, or that two founders disagree about who says yes.

The person who can approve

Name one person who can approve copy, design, and a change of scope. That person should be on the kickoff call and in the project channel. If a second founder, a board member, or a lawyer will also need to say yes, say so before the first screen is drawn, and say when their review happens.

A project with three approvers and no order is a project that restarts. The studio can present to a group. The record of the decision still needs a single name. Write that name down. If that person is traveling during the build, name the deputy and the dates.

Approval also has a speed. A kickoff that leaves "we'll get you notes when we can" as the review plan will slip, because the studio's week depends on a reply. Agree the day notes come back. A weekly review only works if the notes exist before the next block of work starts.

A rough offer, in one paragraph

An OPEN sign hanging in a shop window, with the word SHOP printed on the glass. It accompanies an article about What to have ready before kickoff.

Bring a rough offer, not a finished brand strategy. The useful paragraph says who the site is for, what they can do after they understand it, and what the company refuses to pretend. Three references you like, and one note about what must not change, are enough beside it.

Nielsen Norman Group's finding on the opening seconds of a page is a good test for that paragraph. Jakob Nielsen wrote in 2011 that people often leave a web page in 10 to 20 seconds, and that a page has to communicate its value within about 10 seconds if it wants more of their time. The kickoff offer is the raw material for that sentence. If the founder cannot say it plainly in the meeting, the homepage will struggle to say it plainly in public.

The paragraph can be ugly. "We help independent clinics book fewer no-shows, and the site should get a manager to book a demo" is a strong kickoff sentence. A page of adjectives about innovation is a weak one. The studio's job is to turn the rough offer into a page. The founder's job is to know what the page is claiming.

Access to the site you already have

If a site exists, the studio needs to see it as the people who operate it see it. That means the content login, the analytics, and a way to view the page as it ships, including the mobile width. Screenshots from a sales deck are a clue. They are a poor substitute for the live page, the redirects, and the form that currently receives leads.

Write down what must survive. A URL that already ranks, a checkout a customer knows, a headline regulars look for. On a Hanabi project, public work such as the Thomas Bewick editorial site or the Down the Cove store migration started from what had to remain true, then changed the parts that were failing. Kickoff is when that list gets made. After kickoff, "please also keep this" is a change of scope.

If there is no current site, say that. Bring the domain you intend to use, and say whether the name is settled. A rename during the build touches the title, the email, and the files. It is cheaper to know that on day one.

Accounts that should already be yours

A pale room with an arched opening onto a dark sofa, a low table, and a glass vase of dried stems. It accompanies an article about What to have ready before kickoff.

Own the accounts before the studio is invited in. The domain registrar, the host, the analytics property, and the inbox that receives form replies should be in the company's name. A studio that creates these and keeps the only login is a dependency. Invite the studio as a collaborator. Keep the owner seat.

A practical list for the week of kickoff:

  • Domain registrar login, with the client as owner.
  • Hosting or deployment access, including the place the new site will ship.
  • Analytics, if any, and the search console property for the domain.
  • The current content system, if one exists, and a backup of the copy you care about.
  • Brand files: logo, type, colors, and any photography you already have the right to use.
  • The inbox or tool that should receive new inquiries.

Missing any one of these can be repaired. Missing several of them becomes the first week's work, and the launch date quietly pays for it.

The client portal is where files and docs can live once the project is moving. It does not replace the first-day access. The portal is a home for the work. Kickoff still needs the keys to the systems that already exist.

What can wait until the second week

A few things feel urgent and can wait. A perfect photography set can wait if you have enough honest pictures to design against. A full blog plan can wait if the launch is a marketing site with one offer. A legal page can be a placeholder with a named owner and a date, as long as it is not the page blocking launch.

What should not wait is the primary action. If the site exists to book a call, the destination of that button has to be real: a calendar, an email, or a form someone will answer. Deciding that in week four means the header was designed around a guess.

Copy for the inner pages can arrive in slices. The homepage offer, the proof you are willing to show, and the sentence about who you are should exist at kickoff, even as drafts. Inner pages can follow the structure those drafts imply.

If the first week is already lost

Say so, and reset the date in writing. A studio that pretends production started while it was still waiting on a registrar code is protecting a feeling and damaging the schedule. The honest kickoff is the day access, the approver, and the rough offer are all present.

If you are gathering those pieces and want a second pair of eyes on what is actually required, book an intro call with Hanabi. The call can confirm fit and the shape of the work. The checklist above is what makes the first production week a production week.

A short brief is the companion to this list. How to brief a studio for a marketing site is the next piece, because access without a brief still leaves the studio guessing what the site is for.

Frequently asked questions

What has to be true on kickoff day?

Someone can approve the work, the offer is written in rough form, the studio can open the current site, and the important accounts are in the client's name. Kickoff is the start of production. It is a poor moment to discover that the domain login lives in a former employee's inbox.

Who should approve design and copy?

Name one person, put them on the kickoff call, and agree the day their notes come back. Other people can comment. The written reply from the named approver is the record the studio builds from. If that person will be away, name a deputy and the dates.

Which accounts should the client already own?

The domain registrar, the host, the analytics property, and the inbox that receives form replies should be in the company's name. Invite the studio as a collaborator. A studio that creates these and keeps the only login becomes a dependency, even when the work itself is good.

Sources and further reading

  1. How Long Do Users Stay on Web Pages?, Nielsen Norman Group

Written by

Hanabi

Hanabi is a product design and web development studio. The studio writes about clear websites, brand systems, and product interfaces for founders.

Keep reading

All articles