I take rescue work. Always.

Half-finished sites from a developer who stopped responding. Sites that worked once and don’t anymore. Sites you bought from someone else and can’t extend. Sites that “just need a few changes” but every plugin update breaks something. I take all of those.

The safer answer is “I only build from scratch.” I understand why other developers say it. Rescue work is unpredictable, undocumented, and often emotionally charged for the buyer. I take it anyway, because rescuing other people’s failed work is like rehabilitating a puppy for me. It’s a joy.

What I do

• Require permission to scrape the site at minimum. Ideally full SFTP, database, and scoped access to your domain management for optimization work.
• Run a no-blame audit. The previous developer isn’t the villain of the story. Sometimes the brief was wrong, sometimes the budget ran out, sometimes WordPress just changed faster than the project did. I figure out what’s there before I touch it.
• Quote stabilization first, improvement second. The site needs to be safe and current before it gets better.
• Document what I find. You should be able to read the audit and understand what state your site was actually in when I arrived.
• Build the handoff path so the next developer (whether that’s me again or someone else) can pick up cleanly.

Why this is the position

There’s a craft satisfaction in rescue work that pure greenfield doesn’t deliver. You’re solving a real problem someone is genuinely stuck on, and the constraints are the work. You can’t rebuild from scratch, you can’t pretend the legacy code doesn’t exist, and you can’t hide your work in a rewrite that buries the diagnosis. You have to actually understand what’s there.

There’s also a market argument. Rescue clients become long-term clients more often than greenfield clients do. Someone who’s been burned once and finds someone they trust doesn’t go shopping again.

The puppy metaphor stands. Sometimes the previous home wasn’t great. The dog isn’t ruined. It just needs someone patient.

See also

• WordPress is rarely the wrong tool. On why rescue work is even possible — the platform usually isn't the problem.
• The next developer who opens my code is in a teaching moment. The other side of rescue work — leaving the codebase in a state the next developer can pick up.
• What you owe the people still running your old code. The longer-form piece on what rescue work is actually about.