Running a WordPress Agency: The Operational Spine Nobody Sells You

The hard part of running a WordPress agency is not building sites. It is the twenty-fourth site: whether it is isolated from the other twenty-three, whether you can hand it to the client without a migration, and whether the retainer covers what it actually costs you to keep alive.

There is no shortage of advice on winning WordPress clients and pricing proposals. There is very little on the operational spine underneath — the decisions about isolation, environments, ownership, and per-site cost that determine whether an agency at thirty clients is profitable or quietly drowning. Those decisions are cheap to make early and expensive to change later.

Table of contents

• Multisite or separate installs
• Staging, and why the lack of it costs more than it saves
• The handover problem
• Unit economics per client site
• The tooling that removes the recurring annoyances
• Is the model still viable
• How this fits the rest of the stack
• FAQ

Multisite or separate installs

The first structural decision, and the one most likely to be regretted.

WordPress Multisite runs many sites from one installation, one codebase, one database. It is genuinely appealing: update the core once, manage plugins centrally, spin up a new site instantly.

For a client agency it is usually the wrong answer, for reasons that only surface later:

• A plugin update that breaks one site breaks all of them, because they share a codebase.
• One compromised site is a foothold in the whole network. Client sites contain client data.
• One site’s traffic spike affects everyone on the install.
• Handing a client their site means exporting it out of the network, which is a migration and never as clean as promised.
• Client A’s plugin requirements constrain Client B.

Separate installs cost more in per-site overhead and remove all of that. A problem stays inside one client’s boundary, sites are independently upgradeable, and handover is a transfer rather than an extraction.

Multisite earns its place when the sites genuinely are one thing — a franchise network, a university’s departments, a chain of locations under one owner. The distinction is whether one entity owns all of them. If your clients are separate businesses, keep them separate.

Staging, and why the lack of it costs more than it saves

The most common agency failure is editing production. Somebody applies a plugin update on a live site at 4pm on a Friday, something conflicts, and the client’s checkout is down until it is found and reverted.

The minimum viable process:

• A staging copy of each client site that mirrors production, including PHP version and plugin set.
• Updates applied and checked on staging first.
• A push to production that is a deliberate action, not an SFTP drag.
• A rollback path that does not depend on remembering to take a backup first.
• Backups taken automatically, retained for a known period, and restored at least once so you know the restore works.

That last one deserves emphasis. A backup nobody has ever restored is not a backup. Test one per client per year and you will find the broken one before the client does.

The objection is always time. The arithmetic answers it: one production incident on one client site costs more hours — and more goodwill — than a year of applying updates on staging first. The agencies that skip this do not save money, they defer it into unbillable emergency work.

The handover problem

Every client relationship ends, and how it ends shapes your reputation more than how it began.

Three artefacts determine whether handover is a transfer or a fight.

The domain. It should be registered in the client’s name with the client as registrant, always, from day one. Registering client domains in the agency’s name is common and indefensible. Manage it for them by all means, but do not own it.

The hosting account. Either the client holds the account and grants you access, or you hold it and can transfer it cleanly. What you want to avoid is a shared reseller box where one client’s site cannot be extracted without touching the others — which is another reason multisite complicates the exit.

The code and content. A repository the client can be given, not a folder on your server. Custom theme and plugin work should be under version control from the first commit, and the client should be able to receive that repository at the end.

Agencies that make leaving easy get better referrals than agencies that make it hard. The client who leaves cleanly recommends you; the one who had to fight for their own domain tells that story for years.

Unit economics per client site

The question a lot of agencies never answer precisely: what does one client site cost you per month, all in?

Add up the parts that are actually per-site:

• Hosting for the site itself, including the database.
• Backup storage and retention.
• Any per-site licences — premium plugins, form handlers, security or SEO tools — that are not covered by a developer licence.
• Staging, if it costs separately.
• Monitoring.
• Your time: updates, checks, and the small requests that never get invoiced.

That last line is the one that ruins retainers. An hour a month of unbilled small requests, at your real hourly rate, is frequently larger than every infrastructure cost combined. Agencies price the hosting carefully and give away the labour.

Price the retainer against the total, with the time included at a real rate, and set a boundary for what it covers. A retainer that covers updates, backups, uptime, and thirty minutes of changes is honest and defensible. One that covers everything the client can think of is a loss that grows with the relationship.

For a sense of the infrastructure end: managed WordPress on RunxBuild starts at $3 a month on the Starter plan, with Mini at $5 and Biz at $13 as the sites get busier, each on its own plan rather than sharing a box. Whatever platform you use, the useful exercise is knowing that number per client rather than as one bill you divide by thirty.

The tooling that removes the recurring annoyances

Two things eat agency time disproportionately, and both have straightforward answers.

File access. The traditional route is SFTP credentials, an FTP client, and a set of logins per client that somebody has to manage and rotate. A file manager in the hosting dashboard removes the credential sprawl entirely — browse, edit, upload, and unzip in the browser, with access governed by who is on the team rather than by who has the password.

Database access. The traditional route is phpMyAdmin, which means another login and a tool that is a security consideration in its own right. A database browser in the dashboard — tables, rows, SQL, export, import — covers the actual tasks: checking an option value, exporting before a risky change, fixing a serialised URL after a migration.

RunxBuild includes both in the dashboard for managed WordPress, which is the specific reason it suits agency work: the per-client credential set shrinks to a team membership.

Beyond that, WP-CLI is worth the afternoon it takes to learn if you are managing more than a handful of sites. Updating plugins, searching and replacing across a database, and exporting content are all one command, and one command can be scripted across every site you run.

Is the model still viable

Worth addressing, since the question comes up in every forum thread on the subject.

The commodity end — a five-page brochure site built from a purchased theme — has been eaten by builders and will not come back. Competing there means competing with something that costs the client almost nothing.

What has not been eaten is everything that requires understanding a business: integrations with the systems they already run, custom post structures that match how they actually work, migrations from something old and fragile, performance work on a site that has accumulated eleven years of plugins, and ongoing responsibility for a site that makes money.

That work is more valuable than it was, not less, because the volume of WordPress sites in existence keeps rising and each one eventually needs somebody who knows what they are looking at. The agencies struggling are largely the ones still selling the commodity build. The ones doing well sell the relationship, and the operational spine described above is what makes the relationship affordable to maintain.

How this fits the rest of the stack

The difference between an agency that scales and one that stalls is rarely the design work. It is whether client sites are isolated, whether updates go through staging, whether handover is a transfer, and whether you know the per-site cost precisely enough to price a retainer that holds. Managed WordPress on RunxBuild puts each site on its own plan with a file manager and database browser in the dashboard, which removes the credential sprawl that scales worst. The RunxBuild hosting calculator is the place to work out what one client site costs before you quote thirty of them.

Useful related references:

• WordPress 6.8.2: What a Maintenance Release Is and How to Handle It
• Squarespace vs WordPress: The Question Behind the Question
• WordPress Maintenance Services: What You Are Actually Paying For
• Services on RunxBuild

FAQ

Should a WordPress agency use Multisite for client sites?

Usually not. Multisite shares a codebase and database, so one bad plugin update or one compromise affects every site, and handing a client their site becomes an extraction rather than a transfer. Multisite fits when one entity owns all the sites — a franchise, a university, a chain. Separate businesses should get separate installs.

How much should I charge for WordPress maintenance?

Price against your real total per site: hosting, backups, per-site licences, monitoring, and your time at a genuine hourly rate. The time is usually the largest component and the one agencies give away. Define what the retainer covers — updates, backups, uptime, and a fixed allowance of changes — rather than leaving it open.

What is the right way to hand a WordPress site over to a client?

The domain should already be registered in their name, the hosting account should be transferable or already theirs, and custom code should be in a repository you can hand across. Handovers become fights when the agency owns the domain or the site is entangled in a shared install that cannot be separated cleanly.

Do I really need staging for every client site?

Yes, if you apply updates. One production incident costs more unbillable hours and goodwill than a year of checking updates on staging. Pair it with automatic backups you have actually restored at least once, because an untested backup is a hope rather than a recovery plan.

Is building WordPress sites still a viable business?

The commodity brochure build has been taken by site builders and is not worth competing for. Integration work, migrations, performance rescue on plugin-heavy sites, and ongoing responsibility for sites that generate revenue are all more valuable than they were, because the installed base keeps growing and each site eventually needs someone who knows what they are looking at.