What you should be handed on launch day

The usual handover is a text message with a link in it and an invoice behind it. The site looks good. Everyone’s happy. Six months later the only person who can change anything is the one who has stopped replying.

The list below is 9 items. It’s the same list whether you paid $2,997 or $7,997, and none of it is a favour. This covers the site, the hosting and the domain only — logo and brand source files are a separate handover with their own list.

Accounts that have to be in your name

1. The registrar login for your domain

In your name, on your email address, on your card. You should be able to sign in without asking anyone and see the domain sitting there.

The answer that should worry you is “we manage the domain for you”. That may be convenient and it may be well meant, but it isn’t handover. Ask for the registrar name and the login, and if the arrangement genuinely is that they hold it, get that written down along with what happens when you leave.

2. The hosting account, or a written statement of who holds it

Either you hold the account and the invoice comes to you from the host, or someone else holds it and you know exactly that. Both are workable. The unworkable version is not knowing.

If they hold it, the questions are: what does it cost, what’s the notice period, and what do I get if I leave. A straight operator answers all 3 without going quiet. We don’t host sites ourselves: the hosting account is in your name, paid by you, straight to the host.

3. Owner access to your Google properties

Google Business Profile, Search Console and Analytics. You want to be listed as owner, with whoever built the site added as a manager or delegated user.

Owner and manager are different levels and only one of them can remove the other. Make sure you hold owner access, not just a login that looks like it.

4. Where the email actually runs

The one everybody forgets. If your mailboxes are on the same hosting as the site, they go down when the site does. Ask where mail is hosted, whether it’s the same account as the website, and who holds that login.

If the answer is “same place”, that’s not a fault. It’s a thing to know before the day you need to know it.

Files and evidence you have to be given

5. A copy of the site as it was published

Dated, and in a form you can hand to someone else. On a static build that’s the source files. On WordPress it’s an export plus a database backup, and confirmation that a backup runs on a schedule rather than “we’ve got a backup somewhere”.

You don’t need to understand the files. You need to have them, because they’re the difference between a rebuild and a recovery.

6. The check results, with the warnings still in them

Every page should have been checked against a fixed list before it went live, and you should be handed the result. Ask for it before you pay the final invoice, not after.

The part that matters isn’t the pass. It’s that the warnings are printed rather than deleted. Results showing a few warnings are real results. If every line is clean, ask to see the warnings.

Ask for the site-wide duplication result too. On our builds no two pages are allowed to read like each other, and every page has to carry at least 3 facts that appear nowhere else. That check runs across the whole site, not just the new pages.

7. Proof that a real enquiry went through the form and arrived

This is the one we’d be failing you on if we skipped it.

Your enquiry form goes in pointed at your own inbox, and a person sends a test enquiry through it by hand and confirms it landed before handover.

Hold anyone to the same thing. Ask for the time the test was sent, which inbox it landed in, and whether someone replied to it to check the reply didn’t bounce. A form that submits successfully and delivers nowhere is the most expensive fault a trade website can have, because it fails silently and it fails on the customers who were ready to book.

Things that have to be in writing

8. What a change costs, and how long it takes

Get the rate and the turnaround for a small change before launch day, not the first time you need one. If the build is static and you can’t edit it yourself, that should have been said before you paid, not discovered when your mobile number changes.

We say it plainly: on a static build you can’t self-edit, you send us the change and we make it. If self-editing matters, that’s a WordPress build and it’s a decision made before the build, not after.

9. The domain expiry date, the renewal cost, and who pays it

Three lines in an email. Put a reminder in your phone a month before the date. Domains don’t get lost through malice, they get lost because a renewal notice went to an inbox nobody reads any more.

The version you can send today

If your site is already live and you never got any of this, one email covers most of it. Copy it.

Hi, can you please send me: the registrar and login for the domain, the hosting account details, owner access to the Google Business Profile and Search Console, a dated copy of the site files, and the results of whatever pre-launch checks were run on the pages. Also the domain expiry date and the renewal cost. Thanks.

You’ll get one of 3 responses. The lot, quickly, which tells you you’re in good hands. Some of it with an explanation, which is normal and fixable. Or silence, which has answered a different question you didn’t ask.

If the silence is the answer you get, the domain is the piece to chase first and the rest can wait — the 5-minute ownership check tells you how bad the situation actually is before you start.

Where to look when you don’t know who holds the domain

Most Australian trade domains sit with one of a short list of registrars, and the renewal notice is the fastest way to find yours. Search your email for the registrar names first: Crazy Domains, VentraIP, Netregistry and GoDaddy (or older invoices from Melbourne IT). Any renewal invoice, in any year, names the registrar and the account holder.

If nothing turns up, run a WHOIS lookup on your own domain. For a .com.au or .net.au the auDA registry publishes the registrar name even where the contact details are withheld, which tells you who to ring even when it does not tell you whose account it is.

The answer you are looking for is not “who built it”. It is whose credit card the renewal comes off, because that is the person who can lose you the domain by changing jobs.

Three checks you can run on the handover itself

Log out and log back in. Not with a link somebody sent you — go to the site cold, in a browser you are not already signed into, and get in with the details you were given. This is how a lot of failed handovers get found, weeks too late.

Change one password. If you can change it yourself without asking anyone, the account is yours. If the change bounces or needs approval from someone else, it is not.

Open the source files on a machine that has never touched the project. Files that only open on the developer’s computer are not a handover, they are a demonstration.

Why this is a short list and not a long one

Nothing on it is generous. It’s 4 logins, 2 files, 1 test and 2 numbers in an email. A build where those things exist takes about an hour to hand over properly, because the accounts were opened in your name at the start instead of being untangled at the end.

That’s the whole reason we register the domain first and decide the hosting question out loud before anything gets built. Handover isn’t a task at the end of a build. It’s a decision made at the start, and you can tell which one you’re getting from the first conversation.