What You Need Before Handing a Builder Site to a Client

The handoff of a website to a client is a small, unglamorous event that happens thousands of times a day, and it is where a great deal of quiet professional damage gets done. A builder has spent weeks on a site. The client has paid. Everyone is tired. Then login credentials get pasted into an email, a link is sent, and the project is declared finished. Three months later the client cannot remember the WordPress admin password, the contact form has been silently failing since a plugin update, and nobody knows who owns the domain renewal.

The handoff is not a formality. It is the last chance to prevent a slow cascade of small failures that will all be blamed on the builder. What follows is the checklist that separates a clean handoff from a polite abandonment.

Credentials belong in a password manager, not a Gmail thread

The single most common handoff failure is credential delivery. A builder finishes the site, opens an email, types the admin username and password, hits send, and considers the job done. The client reads it on a phone, half-remembers it, and loses it within a week.

Passwords sent in plain text through email live forever in at least two inboxes and possibly a mail server backup. That is a security problem, but it is also a practical one: the client will ask for the password again, then again, and each request eats time that was never billed.

The clean approach is a shared password manager entry, or a one-time secret link that expires after a single view. The client gets a secure record. The builder keeps a copy in an encrypted vault. Both parties can rotate credentials later without a scavenger hunt through old emails.

There is a second layer to this. The client needs a documented list of every account tied to the site: hosting, domain registrar, DNS, the CMS admin, the email provider, any payment gateway, any third-party service. A single page, exported as a PDF, stored somewhere the client will actually find it. The list matters more than the passwords themselves, because a forgotten account is often harder to recover than a forgotten password.

Domain and hosting should be in the client's name before the final invoice

Builders frequently register the domain and set up hosting under their own accounts because it is faster during the build. This works fine until the relationship sours, the builder's card expires, or the client wants to move to a different host and discovers the domain is locked inside an account they cannot access.

Before the handoff, every domain, hosting plan, SSL certificate, and DNS record should be transferred into an account the client owns, with the builder listed only as a delegate or technical contact. This is not a trust issue. It is a continuity issue. Clients change agencies. Builders retire. Accounts lapse. The client should be the one who receives the renewal notice.

The transfer takes twenty minutes and prevents a category of dispute that can drag on for months. A domain locked in someone else's registrar is the digital equivalent of a deed held by a contractor.

The contact form has to be tested from a real outside inbox

Contact forms break quietly. A plugin updates, an SMTP credential expires, a spam filter starts rejecting the notification address, and the form keeps showing a cheerful "message sent" confirmation while nothing arrives anywhere.

Testing a form from the same machine the builder used to build it proves almost nothing. The real test is to submit from an outside email address, on a different network, and confirm the message lands in the client's actual inbox, not a catch-all folder or a spam quarantine. Then reply to that message and confirm the reply reaches the submitter.

This should be done on the day of handoff, not the week before. A form that worked on Tuesday can fail on Friday.

Backups need a schedule, a location, and a restore test

Most hosts advertise automatic backups. Many of those backups are stored on the same server as the live site, which means a serious failure takes the backup with it. Clients rarely know this until they need it.

A responsible handoff includes a documented backup routine: what gets backed up, how often, where the copies live (ideally off the primary server), and how long they are retained. The client should know who is responsible for checking that backups are actually running.

The restore test is the part almost everyone skips. A backup that has never been restored is a hope, not a plan. A builder who can demonstrate a successful restore of a recent backup, even into a staging environment, has given the client something far more valuable than a reassuring sentence in a contract.

Plugin and theme licenses need to be in writing

Premium plugins and themes come with annual licenses. Those licenses are frequently purchased under the builder's account and renewed by the builder out of habit, or not renewed at all. When the license lapses, updates stop, and the site begins accumulating security gaps that nobody notices until something breaks.

At handoff, the client should receive a plain list of every premium plugin and theme, the license type, the renewal date, and whether the license is being transferred or renewed by the builder as part of a maintenance agreement. If the client is expected to renew, they need the login for the vendor account, not just a note that a license exists.

This is where a lot of post-launch friction begins. A client discovers a $99 renewal they did not know about, or worse, a lapsed license that let a vulnerability sit open for eight months.

Analytics and search console access should belong to the client

Google Analytics, Google Search Console, and any other measurement tools should be set up under the client's Google account with the builder added as a user. When these are created under a builder's account, the client ends up with no historical data if the relationship ends, and the builder ends up fielding data requests months after the project closed.

Search Console in particular carries a record of indexing issues, manual actions, and performance history that has real value. Handing over the property properly means the client keeps that history. Setting it up under the client from the start takes about ten minutes and saves a painful migration later.

Staging environments should be removed or clearly labeled

Many builders leave a staging site running after launch. Sometimes it is password-protected. Sometimes it is not. An unprotected staging copy of a site is a duplicate that can be indexed by search engines, confusing rankings and occasionally exposing content the client did not intend to publish.

Before handoff, either delete the staging environment or confirm it is behind authentication and excluded from search indexing. The client should know it exists and what it is for. A staging site that nobody remembers is a liability sitting on the server, collecting stale credentials and outdated plugin versions.

A short written handoff document beats a long verbal walkthrough

The walkthrough call is useful. It is also forgettable. The client will nod along, ask two questions, and retain almost nothing past the first ten minutes. A short written document, two to four pages, is what they will actually return to when something goes wrong at 11 pm.

The document should cover: where the site is hosted, how to log in, who to contact for what, the backup schedule, the plugin renewal list, the analytics setup, and a short section on what the client is responsible for versus what remains with the builder. It should be written for a non-technical reader and stored somewhere durable, ideally as a PDF the client keeps alongside their other business records.

Builders often resist this because it feels like unpaid documentation. In practice, it is the cheapest form of client retention available. A client who can solve a small problem with a document does not call. A client who cannot will call about everything, forever.

The maintenance agreement should be decided, not assumed

A site handed over without any discussion of ongoing maintenance is a site that will eventually break in a way the client will attribute to the builder. Updates, security patches, backups, and monitoring are ongoing work. Someone has to do them, and the client needs to know who.

That decision belongs at handoff, not six months later when something has already gone wrong. Either the client signs a maintenance agreement, or the client explicitly takes responsibility, in writing, for updates and backups. Both outcomes are fine. The failure mode is the silent middle ground where nobody has decided and everyone assumes the other party is handling it.

A builder who hands over a site with credentials in a password manager, accounts in the client's name, a tested contact form, a documented backup routine, a written handoff document, and a clear maintenance decision has done the job properly. It is not glamorous work. It is the difference between a project that ends cleanly and one that keeps generating small, avoidable crises for years.