Website Project Delivery

Pushing a site live is a technical event that takes minutes. Delivering a website to a client is a different thing entirely. It covers everything that has to happen before the domain points to production, during the handover call, and after the client accepts the work: the quality check, the walkthrough, the written sign-off, the credentials document, and the invoice. Miss any of those steps and you are not done.

Most delivery problems are not technical failures. They are process failures. The site works fine, but nobody agreed on what "complete" means. The client expected one more round of feedback. The credentials are in a Slack message from three months ago. The domain renewal happens to be two weeks out and nobody flagged it. A delivery process makes all of this explicit before the project closes, not after.

Delivery breaks into three distinct phases: a pre-launch technical check (agency-side, before the client sees it), a structured walkthrough call (client-facing, building confidence and collecting a formal decision), and a post-launch handoff (credentials, documentation, and closing the project cleanly). Each phase has its own purpose and its own failure mode. Treating all three as "just the launch" is where things go wrong.

The pre-launch check happens before the client sees the production build. Its purpose is to catch everything that would surface during the walkthrough call and create unnecessary friction. Arriving at a delivery call with broken forms or a missing SSL certificate puts you in a reactive position before you have presented a single page.

Run through the full list on a device you have not been building on. Your development machine, cached in a browser you have had open for weeks, will miss things that a fresh browser or a client's phone will catch immediately.

The walkthrough call is the delivery moment: this is when the client forms their lasting impression of the work. A disorganised call where feedback from three months ago gets re-raised and the mobile view has never been checked is the fastest way to turn a technically excellent site into a disputed project.

Structure the call before you start screen-sharing. Send a short agenda 24 hours in advance: what you will cover, how long it will take, and what decision you need at the end. Clients who arrive knowing the call ends with a go/no-go decision make faster decisions. Clients who arrive with no agenda treat the call as a review session and generate new feedback.

Walk through every page on desktop first, then switch to mobile immediately, without waiting for the client to ask. Most clients do not think to request a mobile demo and will mention it later via email. Showing mobile proactively closes that loop on the call, where the feedback can be collected and handled cleanly. For e-commerce sites, complete a full test checkout during the call with a discount code or test card. Do not assume the client will trust that the checkout works without seeing it.

Sign-off means the client has accepted the work. It does not mean the project is finished on your end. A complete handoff includes a credentials document, renewal information, and a clear record of what the client now owns. Without this, your support inbox receives login requests for years after delivery.

The handoff document should be a PDF or shared file, not a string of emails. Clients do not search their inboxes; they call you. A single document with clearly labelled sections is findable by the client's team and removes your agency from the role of IT support for logins the client should own.