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:
- Backup. A full backup before every update. If something goes wrong, the previous state is back in minutes.
- Test environment. Updates and changes land on a copy first. Do forms work? Custom extensions? Mobile layout?
- 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.
Top comments (1)
Solid writeup — the operational side of freelancing rarely gets documented this honestly.
One trap I'd flag in the staging-as-reset-point routine: if the client (or anyone with editor access) adds pages, posts, or media on live between refreshes, a full restore from staging wipes those changes. Worth excluding the content tables or snapshotting the DB right before the restore, and being explicit with the client about which parts of the site are 'theirs' to change.
Two other things I'd add to that runbook: define('DISABLE_WP_CRON', true) and run the real cron from the server — low-traffic corporate sites will silently miss scheduled posts otherwise. And actually time a full restore once a quarter, so you know your real recovery window before the day you need it.