The request that is smaller than the problem
Most rescue enquiries begin with a specific, modest ask. "The contact form stopped working." "The site is slow, can you speed it up." "The menu is broken on phones." The client wants that thing fixed, for a small amount, and back to business.
Sometimes that is exactly what happens. Sometimes the diagnosis shows that the small thing is a symptom, the fix would cost a meaningful fraction of a rebuild, and it would leave the site one update away from the next emergency. Then the honest recommendation is the one the client did not ask for.
Here are three, anonymised, with the reasoning.
Rescue one: "Just fix the form"
The ask. A landscaping firm's contact form had stopped delivering enquiries. They had lost, they thought, three weeks of leads. Fix the form.
The diagnosis. The form plugin was four years out of date and incompatible with the PHP version the host had just moved to. Updating it required updating WordPress, which required updating the theme, which was a marketplace theme with a bundled page builder, abandoned by its author, and would break on update. The site was on shared hosting with no staging and no backups. Eleven other plugins were similarly stale, two with known vulnerabilities.
The cheap fix. Roll the PHP version back at the host (possible for another few months), patch the form plugin by hand, deliver enquiries again. Perhaps three hours.
What it would have hidden. A site that could not be updated without breaking, on a host about to remove the old PHP version entirely, with two open vulnerabilities and no backup. The next emergency was months away and would be worse.
The call. A rebuild on a block theme with the same twelve pages, the same URLs, proper hosting with staging and backups, and a new form wired to the owner's inbox and tracked in analytics. The cost was several times the fix. The client's view, after a hard conversation, was that they had lost three weeks of enquiries once and did not want to lose them again in the autumn. The rebuild took two weeks. The form has not stopped since.
Rescue two: "Make it faster"
The ask. A dental practice's site took six seconds to load on a phone and their Google rankings had slipped. Speed it up.
The diagnosis. A page-builder site with 340 uncompressed images in a gallery that loaded on every page, three slider plugins, a video background on the home page, fourteen fonts, and a theme that loaded its entire stylesheet everywhere. The builder's optimisation settings recovered about a second on staging. The remaining four seconds were structural.
The cheap fix. Compress the images, apply the builder's performance settings, install a caching plugin, remove two of the three sliders. A day's work, bringing the site from six seconds to perhaps three and a half. Better; still failing Google's threshold.
What it would have hidden. Nothing dangerous, but the goal was rankings, and "less slow" would not move them. The practice would have paid for speed work and seen no commercial result, and the next conversation would have been "the speed work didn't help".
The call. The honest version was: the day of tuning will help a little and will not get you to Good; a rebuild would. The practice was planning a rebrand within the year. The decision was to do the cheap tuning now as a stopgap, explicitly labelled as such, and to fold the rebuild into the rebrand rather than pay twice. Both happened. The rebuilt site loads in just over a second and the Core Web Vitals report is green.
That one is included because the right answer was not "rebuild now". It was "here is what the fix buys and does not buy; decide with that in view."
Rescue three: "The mobile menu is broken"
The ask. A wedding venue's mobile menu had stopped opening after an update. Fix the menu.
The diagnosis. The menu was a third-party plugin that had been abandoned and conflicted with the current WordPress version. Replacing it was straightforward. But the audit found that the site's hosting and domain were in the name of a former marketing manager who had left the company, the site had been quietly hacked (a hidden directory of spam pages, invisible from the front end but indexed by Google), and the theme's customisations had been made directly to parent theme files that the next update would erase.
The cheap fix. Replace the menu plugin. An hour.
What it would have hidden. An active compromise affecting search results for a business whose enquiries came from search, a domain that could be lost if a former employee's card lapsed, and a theme that would revert to its default appearance on the next update.
The call. Fix the menu that day, because a broken menu on a phone is a broken site. Then a short rescue project: clean the hack, recover ownership of the domain and hosting, move to managed hosting, move customisations into a child theme. Not a rebuild. The site was sound underneath; it had been neglected and it had been robbed. The client had asked for an hour of work and got a week's worth of reasons why an hour was not enough, with the menu fixed first so the reasons did not feel like a sales pitch.
The pattern
In each case the client's ask was reasonable and the cheap fix was possible. What distinguished them was what the fix would have left in place: a site that could not be updated, a goal that the fix could not reach, or a compromise and an ownership risk that had nothing to do with the symptom.
The way we make the call: fix the urgent thing if it is genuinely quick and safe; run the diagnosis regardless; write down what the cheap fix would cost, what it would achieve, and what it would leave; write the same for the larger option; and let the client choose with both in front of them. Sometimes they choose the cheap fix with eyes open, and that is a legitimate decision. What is not legitimate is selling the cheap fix as if it were the whole answer.