WordPress Development

The site that nobody can safely touch

There is a specific state a WordPress site reaches after about four years. It works. It is slow, but everyone has stopped noticing. There are between forty and seventy plugins installed, of which perhaps fifteen are doing anything anyone could name. Two of them have not had an update in three years. The theme has been edited directly, so updating it would undo a change nobody has documented, and therefore it does not get updated. There is a backup, probably. Nobody has ever restored it.

That site is not broken. It is unmaintainable, which is worse, because there is no incident to justify fixing it until there is a very expensive one.

A large share of the WordPress work we do starts there. Not a redesign — an inventory. What is installed, what is actually used, what is out of date, what is load-bearing, and what it would take to get back to a site that can be safely updated on a Tuesday. That document is frequently the most valuable thing we hand over, and it costs a fraction of the rebuild that was assumed to be necessary.

What we build

Custom themes. Block themes where the project suits them, classic themes where it does not, and in both cases built as an editing system rather than as a set of screens. Your editors get a library of blocks and patterns that produce pages consistent with the design — not an empty canvas and a page builder, which is how sites end up with nine variations of the same call-to-action band.

We do not build on Elementor, Divi or their equivalents. They solve the first month and charge for it every month afterwards: substantial page weight, content locked into a plugin you can never remove, and a higher price on every piece of work any future developer does. We will happily maintain a site that already uses one — that is most of the rescue work — but we will not create that liability from scratch.

WooCommerce. Catalogue and checkout work, payment and shipping integration, tax configuration, and the caching and hosting decisions that decide whether the store survives a sale day. Which brings up the thing this page ought to say plainly, given that it exists to sell the service.

Headless WordPress. WordPress as the editorial CMS, with the public site rendered by Astro or React reading from the REST API or GraphQL. This is a good fit when the content team is committed to WordPress — years of workflow, a plugin ecosystem they rely on, editors who are fluent in it — and the site itself needs to be faster than a plugin-laden front end is ever going to be. The trade is the usual one: rendering control in exchange for the preview and page-assembly conveniences the admin used to hand you free, which then have to be deliberately rebuilt.

Performance and hardening. A plugin audit, a query profile, a caching strategy that understands what must never be cached, an image pipeline, and an access model where the person who left in 2023 no longer has an administrator account.

WordPress or Shopify

We sell both, so we have no particular incentive to steer you, and the answer is usually clear once the question is asked correctly.

If the store is the business — if most of the revenue and most of the operational attention goes through the catalogue — Shopify is the better platform, and the reason is not features. It is that Shopify absorbs hosting, scaling, PCI scope, payment gateway maintenance, platform patching and checkout security, and those are recurring costs whether or not anyone puts them in a budget. On WooCommerce they are yours. The licence being free is the least significant number in the comparison.

If content is the centre of gravity and commerce is part of it — a publisher with a shop, a service business with a small catalogue, an institution with fifteen years of editorial and a team fluent in the tool — WordPress is the better answer and it is not close. Editorial workflow, taxonomy, multi-author publishing and content modelling are things WordPress has been refining for twenty years.

What we will not do is let a WooCommerce build be chosen because it looks cheaper on the first invoice. It usually is. It is frequently not cheaper by month eighteen, and the difference lands on whoever is on call.

Speed, and where it actually goes

“WordPress is slow” is a claim about a configuration, not about the software. WordPress can serve a page in tens of milliseconds. What it is being asked to do on each request is the variable, and when we profile a slow site the time is almost always in the same four places.

Unbounded database queries added by plugins — a related-products widget doing a full table scan on every page load. Pages not cached at all, or cached with a configuration that quietly excludes everything useful. Images served at the dimensions they were uploaded at, which is to say straight off a phone. And a script and stylesheet payload where every page loads assets for every feature the site has anywhere, because that is what plugins do by default.

None of that is fixed by moving to a bigger server, though that is what usually gets tried first, because it can be bought in an afternoon. It is fixed by an audit, a plugin decision list, and someone willing to remove things.

Legacy, and being straight about it

Our stack includes PHP and ASP.NET, and a share of what we do is platform work on systems that predate everything else on this site. That is not a boast, and it is not an apology either. Businesses run on what they built when they built it, and the useful partner is the one who can keep the old system alive while the new one is stood up — rather than the one who requires everything to be replaced at once before they will help.

In practice this shows up in migrations: a legacy application that has to keep serving a function while the public site moves to something modern, or a decade of content that has to be extracted intact from a system nobody maintains. That work is unfashionable and it is frequently the difference between a migration that happens and one that gets postponed for another two years.

What maintenance actually means

Updates applied on a staging environment that matches production, not on the live site at four on a Friday. Backups taken on a schedule and restored at least once, because a backup that has never been restored is a belief rather than a procedure. A plugin inventory that gets reviewed rather than accumulated. File editing disabled in the admin. Access reviewed when people leave.

It is a boring list, and it is the entire difference between a site you own and a site that owns you.