50. Handing a Website to the Client Without a Panic Week

50. Handing a Website to the Client Without a Panic Week

The last week of a website project is where calm companies panic. Passwords arrive in a rush, the client sees the real content late, and nobody is sure who changes the hours on Friday. A handover without a panic week is mostly a list you start before launch, not a gift you improvise after it. The client should receive access, a short training, the files they will need later, and a written picture of the first fortnight. You should leave with the same picture. Surprise is what turns a launch into a group chat that never sleeps.

This is as true for a five-page shop site as for a larger build. Small sites panic because the founder is also the cashier, and the launch collides with ordinary trade. Plan for that collision. Do not schedule training at the hour they close the till. Do not teach twelve topics. Teach the edits they will really make, and write down the rest.

<Training session with a laptop between two people>

Start the handover list while the site is still being built

The list names the domain and email access, the website admin, the place originals and logos live, the analytics login if there is one, and the retainer or support route. Each item says who holds it and how a second person gets in if the first is away. Fill it as you go. A list written the night before launch will miss the quiet items, such as where the font licence is, or which phone receives the form notifications. Those are the items that cause Saturday calls.

Agree the content freeze. After a certain date, new pages and new offers wait, unless something is actually wrong. A freeze is how you finish. Without it, the client will keep improving the homepage, which is admirable and fatal to the calendar. Put the freeze in the same email as the training time. People respect a date they saw coming. They resent a date invented when you are tired.

Train on the tasks they will do next week

Sit together, in person or on a call, and change a real thing. Hours, a price, a photo, a staff name. Use their login, not yours. Let them type. Correct the path once. Record a short screen capture if they want it, but do not let the capture replace the doing. People remember the click they made themselves. Leave a one-page cheat sheet with those exact clicks, in the language they work in. A twenty-page manual will not be opened when the Raya hours need changing.

  • Logins tested by the client, with a second person named.
  • A cheat sheet for the three edits they will actually make.
  • Where forms go, and a test message they have seen arrive.
  • Logo masters, image originals, and the redirect list.
  • What the retainer covers, and how to ask for something it does not.

Show them how a form arrives and what a failed form looks like. Send a test while you are together. Show them the 404 page and one redirect, so those ideas are not abstract. Show them how to turn a campaign page off if you built one. The training is finished when they can do the cheat-sheet tasks without you speaking. If they cannot, you are not late for applause. You are early for launch, and you should move the date.

<Handover meeting around a project table>

Plan the first fortnight in writing

Write what you will watch and what they will watch. For example, you check that backups and forms work for two weeks, and they check that hours and prices on the site match the counter. Name the channel for bugs, and say what is a bug rather than a new idea. A wrong phone number is a bug. A new section for a service you did not discuss is a quote. This distinction, written down, prevents the panic week from becoming free labour and prevents real faults from being waved away as extras.

Handover is complete when the client can make a normal edit and can reach you about an abnormal one, and both of you know which is which.

Agree a single daily check-in for the first few days, then stop. Constant availability feels like service and trains everyone to skip the cheat sheet. A short check-in at a named time catches genuine launch faults without turning you into overnight staff. If the business trades late, choose a time that respects that, and say when you will not answer. Boundaries are part of a calm launch. They are not a lack of care.

<Checklist and computer on launch day>

Leave the folder and leave cleanly

The folder contains the list, the cheat sheet, the brand files, the archive of the old site if there was one, and the agreement. The client has a copy. You have a copy. Remove shared passwords that were only for the project chat, and confirm the ongoing access the retainer needs. Send one closing note that restates the first-fortnight plan and the date the intensive watching ends. After that date, maintenance follows the retainer, not the memory of launch week.

A panic week is usually a pile of undone small explanations. Spread those explanations into the weeks before launch, train on real edits, and write down the door for bugs. The site can then go live on a day when the shop is simply open. That ordinary day is the real sign of a handover. Not a celebration, not a crisis. A door the client can lock and unlock without you standing beside it.