Someone who already knows your code.
Themes, plugins and dependencies kept current, bugs fixed where they start and features reshaped when the business moves. Looked after by whoever knows how it was built.
Sites don't break. They fall behind.
Nobody goes near it for two years, and then one morning something stops working on its own.
Everything underneath a website keeps moving: the CMS ships releases, extensions get abandoned, libraries expire and the service you wired in rewrites its API. The gap between what you built and what is now assumed widens by itself.
The expensive part is hardly ever the fix. It's talking a stranger through the whole project again.
What I touch, and nothing else.
Brought current
Core, theme, plugins and dependencies updated once I've checked what leans on each piece and what it could drag down with it.
Bugs fixed
When something misbehaves I work out why it happens and fix it in the code, instead of papering over it with one more extension.
Changes and additions
Your business moves on and the site falls short: one more field, a different form, a calculation that now has to work another way.
Inherited code
I take on projects written by somebody else: read the whole thing first, touch it second. Even when no documentation survived.
It starts by reading what's there.
Read
I go through the whole project and note what it's made of, what was touched last and what has sat still.
Sort
I bring forward everything that updates without risk and set down separately whatever needs more care.
Test
Anything that changes is tried far from the live site; only what already works lands there.
Stay
After that, whatever turns up: a fault, a new release, something that has to behave differently.
How you touch a site that already works.
Nothing blind
Before updating I check what leans on that piece. Whatever could take something down with it gets tried.
Away from live
The live site isn't where you experiment. Whatever lands there has already run somewhere else.
In plain words
I tell you what changed and why, without making you follow the technical detail in order to decide.
In your project
Every fix is written inside your project, not left on my machine. If somebody else takes over, it's there.
I maintain what I can read.
I take a project on when I can open its code, follow all of it and answer for whatever I touch. This is the list of what currently falls inside that line.
It nearly always starts here.
Frequently asked questions
What people ask me most before we start. If yours isn't here, just write to me.
Does this include backups and uptime monitoring?
No. Automatic backups and downtime monitoring are your host's job, and most providers already include them. What I always do before any significant change is confirm there's a recent backup and that it actually restores. If your current host doesn't offer backups, I'd recommend moving to one that does.
Do you handle emergencies or offer round-the-clock support?
No. I don't offer immediate response or 24/7 availability. I work on scheduled tasks, which means every change gets tested properly before it reaches your live site. If your business needs someone answering within minutes at any hour, an on-call provider is a better fit. If what you want is a site that's looked after well and consistently, that's exactly what I do.
How is maintenance priced?
It's agreed per site, based on the work involved, so there's no one-size rate. A simple site with a few plugins doesn't cost the same as a store with integrations or a project that's two years behind. I look at the project first and then propose how we'd work, at rates well below agency pricing. Send me your site's address to get started.
What access will you need?
Just enough to work without asking you for something at every step: the admin dashboard, hosting or server access (FTP or SSH), the code repository if there is one, and accounts for connected services such as your payment gateway. I'd recommend creating separate users for me rather than sharing yours, so you can revoke them whenever you like.
What if an update breaks something?
That's why updates are tested on a copy of the site first: most problems surface there and never reach your live site. If something still fails in production, I roll back to the previous version, find the cause and fix it before trying again. I walk through the whole process in how often to update WordPress plugins.
What if my site hasn't been touched in years?
Then we start with a one-off catch-up, which takes more work than the ongoing care because versions have to be brought forward carefully. Sometimes rebuilding a part is cheaper than continuing to patch it. If that's the case I'll say so, and that part would move to web development or online stores.
When was your site last updated?
Pass me the address and whatever you know about how it was built, however little. I'll look at it from the outside and tell you what I find and what I would do about it.