The WordPress Support Request We Usually Say “No” To

29 May 2026

A Digital Dispatch by Marcus Wilson, Director

Wordpress

There’s a particular kind of email that lands in our inbox every few weeks or so.

Usually, it arrives with a slight sense of exhaustion behind it, sometimes frustration, occasionally panic.

A communications manager, charity director, or operations lead gets in touch to ask whether we’d be willing to take over the support and maintenance of their existing WordPress website because things with their current developers haven’t gone especially well.

And I always feel for them when those conversations happen, because by the time somebody reaches out like that, it’s rarely just about a broken plugin or a missed update. More often than not, it’s the culmination of months — sometimes years — of feeling stuck with a website that nobody really understands anymore.

The difficult part is this:

In most cases, we politely say no.

Not because we don’t want to help, and certainly not because we think WordPress itself is the problem.

In fact, quite the opposite.

We’ve built our business around WordPress for years because we genuinely believe it’s one of the best open-source platforms available. Flexible, adaptable, endlessly extendable, and supported by a global community of people constantly improving it. There’s something reassuringly democratic about that.

But like old houses, websites reveal a lot about how they were put together once you start lifting the floorboards.

And that’s where things can become complicated.

The Digital Equivalent of Inheriting Somebody Else’s Wiring

Imagine helping a friend renovate an old flat. On the surface everything looks perfectly reasonable; freshly painted walls, modern fittings, nice lighting.

Then an electrician opened a panel in the hallway and just stood there silently for a moment.

Eventually they say: “Well… it just about works, but…”

This perfectly describes how we often feel when we first look inside some inherited WordPress websites.

On the outside, the site might appear functional enough. But underneath, there can be layer upon layer of short-term fixes, overlapping plugins, abandoned themes, mystery customisations, expired licences, page builders fighting against each other, and code nobody has touched in years because everyone’s quietly afraid of breaking it.

Sometimes there are fifty or sixty plugins installed when half a dozen well-chosen ones would have done the job better.

Sometimes the original developers have vanished entirely.

And sometimes the website has become so dependent on one specific setup that even the smallest update feels like removing a brick from the bottom of a Jenga tower.

The Problem With Supporting a Site You Didn’t Build

One of the misconceptions around website support is that another developer can simply “take over” a project quickly and easily.

In reality, supporting an unfamiliar website can mean learning an entire ecosystem from scratch.

We have to understand how it was built, why certain decisions were made, what functionality is critical, what’s fragile, what’s redundant, and what might unexpectedly fall over during routine maintenance.

That takes time. Quite a lot of time, actually.

And unlike websites we’ve designed and developed ourselves, we don’t have years of understanding sitting behind every decision. We’re learning somebody else’s logic from scratch, often without documentation, context, or a clear structure to work from.

Which means clients end up paying for investigation as much as support.

That never feels particularly good for anybody involved.

We’d much rather spend time improving a website than deciphering it.

Why We Often Recommend Rebuilding Instead

This is usually the moment in the conversation where things become slightly awkward.

Because nobody wants to hear that the website they invested heavily in two or three years ago might need to be rebuilt properly.

I completely understand that reaction.

Budgets are tighter than they’ve ever been, especially for charities, membership organisations, and public sector teams already trying to do extraordinary work with limited resources.

But sometimes rebuilding genuinely is the more cost-effective and less stressful option long term.

When we build websites at Pooka, we do it knowing we’ll likely be supporting them for years afterwards. That changes how you approach development.

You keep things lean.
You avoid unnecessary complexity.
You choose plugins carefully.
You build to WordPress standards.
You think about accessibility, sustainability, performance, training, and future flexibility from the outset.

Because eventually somebody new will inherit that website internally too.

And they deserve a platform that feels understandable rather than intimidating.

Building Websites That Last

I think one of the wider issues in our industry is that too many websites are still being built to launch rather than being built to last.

There’s a difference.

A website can look impressive on launch day while still being incredibly difficult to maintain six months later.

And when support becomes expensive, confusing, or reactive, organisations lose confidence in the very tools that are supposed to help them communicate with the world.

That has never sat comfortably with Pooka.

We’ve always believed the best digital partnerships are built on steadiness, trust, and long-term thinking. The invisible kind of support where things simply work, people feel looked after, and nobody has to panic every time WordPress releases an update.

Maybe that’s a slightly old-fashioned way of looking at things. But then again, old-fashioned isn’t always a bad thing. Most things are still worth building properly the first time around.

The One Exception to the Rule

Now, like most good rules, there’s usually an exception.

If an organisation already knows they’re likely to rebuild their website within the next year or two, we’ll often make exceptions and support an existing site for a finite period of time.

And some of our strongest client relationships have actually started exactly this way. Not with a shiny launch project, but with an honest conversation.

In those situations, the relationship feels very different. We’re not pretending the current website is a perfect long-term foundation, and the client isn’t expecting miracles from a system that may already be showing its age. Instead, it becomes about stability, trust, and creating a sensible bridge between where things are now and where they need to go next.

Sometimes that means keeping the lights on while a fundraising application is underway. Sometimes it means helping an overstretched comms team regain a bit of confidence in the website again. And sometimes it simply means giving people breathing room to plan properly rather than rushing into another rebuild under pressure.

Those kinds of projects can actually become some of the most rewarding relationships we have.

Because underneath it all, what most organisations are really looking for isn’t just technical support. They’re looking for calm, honest guidance from people who care about helping them get to a better place long-term.

So if you’re reading this while quietly despairing at your current website setup, please don’t take this blog as a sign not to get in touch.

Quite the opposite.

Even if the answer isn’t always the one people hope for initially, we’re always happy to have an honest conversation about where things stand, what’s realistic, and what the best next step might be.