Short answer: the hard part of running twenty client sites is not capacity, it is repetition. Every task that takes five minutes on one site takes a hundred minutes across twenty, and the tasks arrive whether or not you scheduled them. The decisions that actually control your workload are made early and quietly: one hosting account or one per client, how updates happen, how you get access without holding passwords, and what your offboarding process looks like. Get those four right and fifty sites is manageable. Get them wrong and fifteen is already painful.
This is what changes as the number goes up, and what to decide before it does.
The decision that shapes everything: one account or one per client#
Almost every other operational question follows from this one, and it is usually made by accident on the second or third client.
| Everything in your account | One account per client | |
|---|---|---|
| Billing | You bill clients, you pay the host | Client pays the host directly |
| Your margin | Whatever markup you set | Commission, or nothing |
| Support calls | Yours | The host’s |
| Client leaves | You perform a migration | They keep the account, you hand over |
| One site compromised | Abuse complaint lands on you, for all sites | Lands on that client |
| Your admin burden | Billing, dunning, tax, support hours | Close to none |
| Client sees the real cost | No | Yes |
| Failure concentration | Every client depends on your account | Independent |
The consolidated version looks obviously better at three clients and gets steadily worse. The two costs that grow fastest are support and concentration risk. You become the support desk for everything, including problems you did not cause, and you become a single point of failure for every client at once. The commercial arithmetic is less favourable than it appears, and the branding case for consolidating is weaker than it appears.
If you are early enough to choose, choose one account per client. If you are already consolidated and it is working, the trigger to revisit is the first abuse complaint or the first messy departure.
Updates at scale#
Updates are the task that defines whether client hosting is a business or a chore, because they never stop and they are never urgent until suddenly they are.
There are three strategies and only one of them survives twenty sites.
Manual, on a schedule. You log into each site monthly and update it. This is defensible at five sites and impossible at thirty. It also means the window between a vulnerability being disclosed and you patching it is up to a month, which is far too long for anything being actively exploited.
Automatic, unattended, everywhere. WordPress will do this for you. The problem is that an update that breaks a client’s site at 3am is worse than the vulnerability it fixed, and you find out when the client does.
Automatic with a safety net. The version that actually works takes a restore point before updating, applies the update, checks the site still responds, and rolls back if it does not. That turns unattended updating from a risk into the default, which is the only way the numbers work at scale.
What separates hosts here is whether the platform does the third one for you, and whether it acts on plugin vulnerability severity rather than treating every update identically. A critical vulnerability in a plugin on four of your client sites deserves different handling from a minor version bump, and doing that triage by hand across a portfolio is a job.
For the sites where an update genuinely cannot be automatic, usually anything with heavy customisation, you need a staging copy that is one action to create rather than a twenty-minute chore. If staging is hard, you will skip it, and you will eventually test in production on a client’s site.
Access at scale#
At three clients you keep passwords in a vault. At thirty that vault is a liability, and it is the thing a security-conscious client will eventually ask you about.
The problems compound quietly. Staff leave and you have to rotate credentials across every client. Nothing in any audit log distinguishes your junior developer from the client themselves. If a client asks who changed a setting, you cannot answer. And you are holding credentials that, in the event of a breach at your end, expose every client you have.
The arrangement you want is delegated access: the client owns the account and grants your login permission to work in it, revocable by them, with your actions attributed to you. It is worth confirming a host supports this before you commit a portfolio to it, because plenty do not, and retrofitting is a project.
Whatever the host offers, keep your own side clean. One login per person rather than a shared agency account, removed on the day someone leaves rather than at the next review. This is the same discipline as WordPress user roles inside the sites themselves, and agencies are usually stricter about the second than the first, which is the wrong way round.
Knowing before the client tells you#
The difference between a good agency and a stressful one is often just who notices first. A client discovering their own site is down and calling you is a worse experience than you emailing them that it was down for four minutes and is now fine, even though the outage is identical.
At scale you need uptime monitoring you did not configure per site. Checks that come with the hosting are the ones that actually stay configured, because nobody has to remember to add them when a site goes live. If you are configuring monitoring manually per client, it will drift, and the site that is not monitored will be the one that goes down.
The same applies to certificate expiry, disk usage and performance regressions. Any of these that require a per-site setup step will eventually be missing on the site where it matters.
Backups at scale#
Two questions matter, and the second is the one that gets skipped.
Can you restore one client’s site, or one file, without restoring everything, and without opening a support ticket? Granular restore is the difference between a ten-minute fix and a bad afternoon.
And is there a copy somewhere other than the platform? Backups on the same infrastructure as the sites protect you against a client deleting a page. They do not protect you against the scenario you are actually insuring against. Some hosts let you push copies to storage you control, which means an independent copy exists regardless of what happens upstream. For a portfolio of client sites, that is worth setting up once.
Plugin-based backups are the fallback rather than the plan. They run inside the site, so they are unavailable in exactly the situations where you need them most, and the limitations are worth understanding before a client is relying on them.
The offboarding runbook#
Write this down before you need it, because you will need it while you are annoyed.
Clients leave. Some of them leave badly. The process should cover: transferring or confirming account ownership, removing your access, removing your team’s access, handing over any third-party credentials that were yours, and confirming backups and monitoring are either transferred or stopped. Then actually remove the access rather than leaving it in place because it is easier.
Agencies routinely leave themselves with access to former clients’ sites for years. It feels harmless and it is not. You are carrying liability for something you no longer manage and no longer get paid for, and if that site is compromised later, your credentials are in the logs.
If each client owns their own account, this is a five-minute process. If everything is in your account, it is a migration, and that difference is the single strongest practical argument for the split.
What breaks at what number#
Roughly, and from watching where it goes wrong:
Around ten sites. Manual updates stop fitting in the month. This is usually the first thing to break, and the symptom is sites running versions you would not admit to.
Around twenty. The password vault becomes a real risk and your billing admin becomes a real job if you consolidated. You start losing track of which client is on which plan and which invoice covers what.
Around thirty. Anything requiring per-site setup has drifted. Some sites have monitoring, some do not. Some have staging, some do not. Nobody decided this; it accumulated.
Around fifty. Concentration risk becomes the dominant concern. One abuse complaint, one compromised site, or one lapsed payment can affect everything at once if it is all in one account.
The pattern is consistent: the failure is never capacity. It is always a per-site manual step that quietly stopped happening.
Where management dashboards fit, and where they do not#
Most agencies at this scale reach for a multi-site management dashboard. These connect to each WordPress install and give you one screen showing updates, backups and uptime across the portfolio. They solve a real problem and they are worth using.
It is worth being clear about what they are, though, because agencies routinely treat them as infrastructure and they are not. A dashboard of this kind connects through a plugin installed inside each site. That means it shares every failure mode of the site it is watching. If a site is down, hacked, out of memory or locked out by a broken plugin, the dashboard is reporting on a site it can no longer reach, which is precisely the moment you needed it.
The practical split is this. Anything that must work when the site does not should come from the hosting platform rather than from inside WordPress: uptime checks, backups, restore, and access. Anything that is about convenience across a portfolio is a good fit for a dashboard: seeing at a glance which sites have pending updates, running bulk plugin updates, and keeping a content inventory.
Treating a dashboard as your backup system is the specific version of this mistake that costs people real data. A backup taken by a plugin, stored by that plugin, and restored by that plugin has a single point of failure running through all three, and it is the site itself.
Per-client documentation nobody wants to write#
The last thing that breaks at scale is knowledge, and it breaks silently.
At five clients you remember which one has the weird DNS arrangement, which one’s contact form posts to an external system, and which one must not be updated during their sale week. At thirty you do not, and neither does the person who joins next year.
Keep one page per client, wherever your team actually looks. It needs: who owns the domain and where it is registered, who owns the hosting account, what is unusual about the site, what must not be touched without asking, and who to contact when something breaks. That is five lines and it will save you a day at some point.
The single most valuable line is the last one. The worst version of a client outage is not the outage, it is discovering that the only person with the client’s mobile number is on holiday and the site has been down since Friday.
Where Hostney sits#
The model we run is one account per client, owned and paid for by the client, with you working inside it through delegate access they grant and can revoke. Your actions appear in the account’s own activity log as yours. That is the arrangement that makes offboarding a five-minute job instead of a migration.
Worth stating plainly: delegate access is all-or-nothing per hosting account today. Scoped and read-only access is not available yet, so a delegate can do what the owner can do. If your workflow needs a junior with limited permissions, that is a real gap.
Sites run in isolated containers rather than sharing one system account, so a compromise on one does not have a path to the next. Automatic updates take a restore point first and check the site responds afterwards, and vulnerability severity drives what gets acted on rather than everything being treated the same. Uptime monitoring and staging are per-site features you do not configure separately, which is the property that stops them drifting. Backups can be copied to S3-compatible storage you control, so an independent copy exists outside our platform.
Free migration is performed by a person and covers the sites you already have elsewhere, which matters if you are consolidating a portfolio rather than starting from nothing. Commercially there is a partner programme rather than a reseller tier, with current rates on the partner page.
Summary#
Capacity is never the problem. Repetition is.
Decide account structure deliberately rather than by accident, and prefer one account per client unless you genuinely run a helpdesk. Make updates automatic with a restore point and a health check, because no other update strategy survives twenty sites. Get access delegated rather than shared, so departures are clean and actions are attributable. Put monitoring and staging on the platform rather than in a per-site setup step, because anything manual will be missing on the site where it matters.
Then write the offboarding runbook while you are calm, and check what a host actually absorbs before you commit a portfolio to it. The criteria that matter for an agency are not the ones on the comparison pages, and the hours you save are worth considerably more than the plan price you are comparing.