WordPress & WooCommerce Development.

For content-led sites where non-technical people publish regularly, yes, and the reasons are economic rather than technical: a deep hiring pool, inexpensive hosting, an editor your team already understands, and an extension market covering most common needs without development. It is a weaker fit for application-like products, and for sites where frontend performance is the primary constraint and the theme layer is what stands in the way.

When the requirement is specific to how your business operates and no supported extension covers it properly — custom content types, integrations with systems that have no connector, WooCommerce behaviour outside the extension market, or logic that must be tested and owned. If a well-maintained plugin genuinely does the job, using it is the correct engineering decision.

High-Performance Order Storage moves WooCommerce order data out of the WordPress post tables into dedicated order tables, and it is the default for newer installations. It matters because any extension that touches orders must be HPOS-aware. If one is not, the store either runs in compatibility mode — synchronising to both tables — or the upgrade is blocked until that extension is updated or replaced.

Not automatically. Customisations written as PHP hooks against the classic checkout do not carry over to the block-based cart and checkout, which is a separate flag and a different extension surface built around blocks and the Store API. Any checkout modification needs to be assessed and usually reimplemented, and that work should be scoped explicitly rather than assumed.

The count is the wrong measure entirely. Twenty lightweight, well-written plugins can outperform three that make uncached external API calls on every page load. What matters is what the active stack actually does per request, which needs profiling rather than counting. The real risk of a large plugin surface is unknown dependencies and risky updates, not the number itself.

Caching improves server response time for anonymous visitors and nothing else. Render-blocking CSS, oversized hero images, font loading, heavy JavaScript and third-party tags are entirely unaffected, and logged-in, cart and checkout journeys usually bypass the cache completely. Diagnosis starts with field data on the actual template rather than a synthetic score on the homepage.

Usually. It starts with an audit — hosting, code quality, plugin inventory, custom modifications, backup verification and access recovery — so both sides know what is being inherited. Undocumented core or plugin modifications are the common complication, and they need a remediation decision before any ongoing support arrangement is meaningful.

Shopify is worth considering when you want hosted reliability and a standard checkout with minimal operational burden, and your catalogue fits its model. Headless is worth it when frontend requirements genuinely exceed what a theme can deliver. Both trade away the thing WordPress is best at — a familiar editor and a deep extension market — so the decision should follow who operates the site rather than what sounds more modern.

Core, plugin and theme updates with regression checks on the journeys that matter, backups with tested restores, uptime and error monitoring, security and vulnerability review, performance checks, and a documented response path with a named owner. Pricing follows change frequency and business risk rather than site size — a transactional store needing rapid response costs considerably more than a brochure site.

By establishing the entry point first. Most compromises come from an outdated plugin or theme, weak administrator credentials, or a compromised hosting account, and restoring a backup without closing that cause reliably results in reinfection. Hardening then means least-privilege roles, protected authentication, dependency management, file and account change monitoring, and a restore procedure that has actually been tested.

WordPress runs some of the largest publishers in the world, so the platform is rarely the limit. Problems come from uncached dynamic pages, expensive database queries, unoptimised media and plugins making external calls per request. Capacity planning should start from a load profile of the real journeys — including checkout and search, which are the ones that cannot be cached.

You should, from the beginning rather than at handover. Repository, environments, domain, hosting and any third-party service accounts in your organisation's name, with deployment and rollback documented. Custom plugins and themes should be delivered as source with their licences listed, so moving to another developer is a decision rather than a negotiation.