How to Host Client Websites: Whose Account, Whose Bill, Whose Problem

Most advice about hosting client websites answers the wrong question. It compares hosts, prices and features, when the thing that actually causes trouble years later is not which host you picked. It is whose name is on the account.

This is written for the freelancer or two-person shop delivering sites to local trade businesses, where the client is not going to manage any of this and does not want to.

The four things, and only one of them is hosting

A website that a business depends on is really four separate arrangements that people talk about as one thing:

1. The domain. The name itself, rented from a registrar.
2. DNS. The records that say where the name points, including where email goes.
3. Hosting. Where the files actually live and get served from.
4. The code. The repository or the files themselves.

They can all sit in one account or in four different ones. Almost every ugly situation in this line of work comes from nobody having written down which is which. The plain-English version of this for the business owner is in the guide on who owns your website, and it is worth sending to a client before the argument rather than during it.

Whose account: the three arrangements

Everything in the client's own accounts, you have access. The client signs up, the card is theirs, you are added as a collaborator. This is the cleanest arrangement and the hardest to sell, because it means walking a plumber through creating three accounts before you can start. It is also the one that makes you easy to leave, which is exactly why clients trust the people who offer it.

Hosting in your account, domain in theirs. The most common working compromise. You keep deploys, previews and environment settings in one place you control, and the thing that cannot be replaced stays with the client. If you disappear, they lose the deployment and keep the name, the email and the traffic. A new developer can put the site back up in an afternoon.

Everything in your account. Fastest to set up and the one that quietly builds a liability. Every client you sign is another business whose entire online presence depends on your card not expiring and you not losing interest. It also makes an honest handoff nearly impossible later, and handoffs are covered properly in the guide on handing a website over to a client.

The rule worth adopting is narrower than it sounds. You do not need to give away control of the deployment. You need the domain, the business email and the Google Business Profile to be in accounts with the client's name and the client's card on them. Those three are the ones that cannot be rebuilt.

The bill, and how to talk about it honestly

Static hosting for a small trade business is free or close to it on the common platforms, and the traffic a local service business sees is nowhere near a paid tier. That creates an awkward moment when you want to charge a monthly fee.

There are two honest positions and one dishonest one.

Honest: charge nothing for hosting and charge for a maintenance agreement that does real work. Honest: charge a monthly fee and describe it as what it is, which is being on call, keeping the site alive and carrying the risk. Dishonest: invoice for hosting, let the client assume they are buying server capacity, and pocket the difference.

The reason to care is not only ethics. Clients find out. A business owner who learns in year three that their $40 a month bought a free plan does not renegotiate, they leave and they tell people. What to charge and how to structure it is covered in what to charge to build a small business website.

Costs that genuinely are yours to pass on: the domain renewal, any paid email plan, a form or transactional email service above its free tier, and any paid host you actually use. State each one, at cost or with a stated markup. The line "here is what this costs, and here is what I charge on top for handling it" has never lost anybody a client.

Email is the part that goes wrong

If you take one operational habit from this guide, take this one.

The business's email almost certainly runs on the same domain as the website, through DNS records that have nothing to do with where the site is served. Change nameservers to point at a new host, and unless those records travel with you, the phone keeps working and the email silently stops. For a trade business, that means quotes, supplier confirmations and job requests vanishing with no error message anywhere.

The sequence that avoids it:

• Record every existing DNS entry before you touch anything. MX records, any SPF, DKIM and DMARC entries, and any subdomain in use.
• Prefer changing individual records over changing nameservers when the client's DNS is already working and email is live on it.
• If you must move nameservers, recreate the mail records at the new provider first, then move.
• Send a test message in and out afterwards and have the client confirm on their phone, not on a webmail tab you opened.

The full ordering for a provider change, written for the owner, is in how to switch website providers.

What free hosting actually covers, and where it stops

For a five to ten page static site for a local business, a free tier is not a compromise. It is the correct answer. The site is a handful of pre-rendered pages, the traffic is a few hundred visits a month, and there is no database.

The places free tiers genuinely run out:

• Commercial use terms. Some free tiers permit personal projects only. Read the terms rather than assuming, because a client site is commercial by definition.
• Server-side work. Contact forms, search, anything with a route handler doing real work. Small volumes are usually fine and heavy use is not.
• Email delivery. Sending mail is almost always a separate service with its own free limit.
• Bandwidth on a site full of unoptimised photos. Trade sites are photo heavy, and the fix is compressing the images rather than upgrading the plan. Photo handling is covered in photos for a contractor website.

The setup that survives you

Write down, for every client, in one place you can find in two minutes: registrar and account holder, where DNS is managed, host and account holder, repository location, form or email service, who has the logins, and the licence for whatever base the site is built on. That last one is the item people forget, and it is the one the next developer will need; ours is published at the Site Kit licence so it can be copied into that record without a support email. It takes ten minutes per client and it is the difference between a professional handover and a week of apologies.

Then ask the honest question about each site. If you stopped work tomorrow, could a competent stranger take it over with what the client already holds? If the answer is no, the gap is worth closing now, while it is administration rather than a crisis.

The short version

Pick hosting on what it costs to run and how easy it is to hand over, not on features nobody will use. Keep the domain, the email and the profile in the client's name. Charge for the work you do rather than for the server, and say which is which. Copy the mail records before you touch DNS.

None of that is technically difficult. It is just the part that gets skipped because the site launched fine without it.