Deciding which sites share an account and which stay separate
Draw the boundary around commercial ownership, not around technical convenience. Sites you own outright can sit together in one billing account. Anything a client, a partner or a future buyer has a claim on gets its own account, even when merging it would be cheaper and tidier to administer. An account is a legal and financial container first, and a folder of websites second.
The four questions that decide it
Ask these about each site before you place it. A single answer of "someone else" is enough to justify a separate account.
- Whose name goes on the account, and whose name is on the invoice that pays for it?
- If this site stopped paying, whose other sites would go dark alongside it?
- Could this site be sold, gifted or handed back on its own, without the rest?
- Does anyone outside your own team need a login that touches it?
| Situation | Placement | Reason |
|---|---|---|
| Your own portfolio of projects, all funded from one pocket | Share one account | Single owner, single payer, nothing to unpick later |
| Client sites you build and bill for | Account each, in the client's name where possible | Their asset, their renewal, their exit |
| A joint venture with a partner | Separate account | Ownership can change before the sites do |
| Staging or throwaway experiments | Share with the parent project | Nobody will ever buy them |
| A site you are grooming to sell | Separate it before you list it, not after | A clean handover raises what a buyer will pay |
What one account really shares
- One payment method and one suspension trigger. A declined card takes down every site on the account, not the one that caused it.
- One control panel login whose scope is the whole account. Per-site FTP users, database users and mailboxes narrow file access, they do not narrow the panel.
- One support relationship. The named account holder is who we can act on instructions from, which matters the day a client and a former developer both make requests.
- One renewal date after consolidation, which is convenient until the year you want to drop only one site from the bundle.
The non-payment case, in numbers
five client sites, one shared account, you as account holder
month 4: client C stops answering invoices
your options
absorb C's share you fund a site you do not own
let the account lapse A, B, D and E go down with C
migrate C out under pressure unpaid work, done to a deadline
same five sites, five accounts
C lapses on its own schedule, nobody else noticesThe shared version has no cheap option. That is the real cost of consolidation, and it is not visible on the invoice that made consolidation look attractive.
Handing over a single site
From its own account, a handover is a change of account contact and payment method, agreed in writing and finished the same day. From a shared account it is a migration: copy files, export and import the database, recreate mailboxes, repoint DNS, reissue certificates, then detach the domain. That is hours of work plus a cutover window, and the buyer inherits none of the site's ticket or billing history because that history belongs to the account, not the site.
Passwords and permissions
A shared master password has no audit trail, so you cannot answer who changed what. Worse, every departure forces a rotation that touches every site in the container. Issue contractors scoped credentials for the specific site, keep the account login inside the owning business, and treat any request to share it as a signal that the site belongs in its own account. Wider estate hygiene lives under running your estate.
Rule of thumb
One account per party that could ever invoice you, be invoiced by you, or sell what is inside it. Group by who owns the asset, never by who happens to administer it this quarter. If you are unsure how an existing arrangement should be split before it becomes a problem, talk to us while nothing is on fire.
Still not sure which way to go?
Tell us what you are building. If it needs less than you think, we will say so.