How I Manage a Corporate Client's Websites as a Solo

One corporate client, several websites, a steady flow of new project sites — and on the other side, one person. Most people assume that takes an agency.

I look after exactly that kind of website landscape for a corporate client. Here's how it works day to day, and where the limits are.

The ground rules

• No update without a backup
• Nothing goes live untested — test environment first, then production
• Maintenance in fixed intervals, not "whenever there's time"
• Monitoring, so problems surface before anyone calls
• Short paths: Teams and phone instead of a ticket system

The starting point

Corporate work rarely is one big project. It's many small ones, in three streams:

• Maintenance: WordPress core, theme and plugin updates, security, performance
• Changes: new content, adjusted pages, new or extended features
• New pages: project websites that have to fit the existing landscape

None of it is big on its own. Together it adds up — and because several sites are involved, every mistake multiplies. An update that breaks a plugin may break it on several sites at once. So everything depends on routines.

Updates never go straight live

The most important rule is the simplest one: nothing gets tried out on production. Every update and every change follows the same order:

1. Backup. A full backup before every update. If something goes wrong, the previous state is back in minutes.
2. Test environment. Updates and changes land on a copy first. Do forms work? Custom extensions? Mobile layout?
3. Live. Only when everything works on the copy does it go to the real site.

It takes a bit longer than clicking "update". Worth it: a bug on staging is annoying; a bug on a corporate website is a problem other people notice.

Sites of the same client usually share plugins and custom extensions. An update that breaks one will likely break the others. Catch it on staging, and you've prevented it several times over.

Fixed intervals instead of constant firefighting

Updates are bundled, tested together and deployed together, in fixed intervals. For me that means one thoroughly tested state instead of five half-tested ones. For the client it means predictability — nobody gets surprised by a change that slipped in between.

Monitoring: see problems before the client does

Sites can fail without anyone touching them: server issues, an expiring certificate, an external service that stops responding. So everything is monitored continuously. If something breaks, I hear about it — ideally before anyone at the client notices.

Good support is invisible. It stands out by nothing standing out.

Short paths: Teams and phone, no tickets

Requests come to me directly via Teams or a quick call. No ticket system, no project manager, no account manager. Whoever asks talks to whoever builds.

That works because one person knows every site and every extension. "The new contact person is missing on the project page" needs no briefing — I know which page, how it's built and where the data lives.

In an agency, the same request often gets logged, handed to someone who may not know the site, then reported back. Every handover costs time and risks losing something.

New project websites: designer + one developer

Project sites are built individually: a designer delivers the design, I implement it. That's more than the page itself:

• it has to fit the existing landscape technically — same plugins, same standards, same update routine
• from day one it's backed up, tested and monitored like the others
• and it stays with me: whoever built it maintains it

The designer focuses on how it looks; I focus on what keeps it stable and maintainable for years.

Where the limits are

One person can't do everything. Three limits belong on the table:

• No 24/7 on-call. If you need guaranteed response times at night, you need a team in shifts.
• No large parallel project. If a project needs five developers at once, an agency is the better fit.
• Absences have to be planned. Holidays are agreed early so nothing critical falls into that window.

Against the biggest risk — everything depending on one person — one rule helps: code and access stay with the client. Everything is built so any other developer could pick it up. The relationship lasts because it works, not because the client is locked in.

When the model fits

Client size is no argument for an agency. The kind of work is. A steady stream of updates, changes and new pages on systems you need to know benefits more from continuity than from team size — and that's exactly what one person who stays provides.

Full write-up on hafenpixel.de. If you've built a similar setup — or hit its limits — I'd like to hear about it in the comments.