WordPress design and development

Built around templates, not pages

The difference between a site your team maintains and one that ossifies is whether it was built as templates or as a set of individually hand-assembled pages. We define the page types first — service page, case study, article, landing page — and build each as a reusable template with defined content slots.

That means a new service page is a content task, not a development task. It also keeps the design consistent as the site grows, which matters more than any individual page looking clever.

A performance budget, agreed in advance

Most WordPress sites get slow the same way: a page builder, a slider, four analytics tags and a plugin for something a theme already did. Each addition is defensible on its own and the total is a four-second load.

We agree a budget before the build — a target for Largest Contentful Paint and a ceiling on page weight — and every plugin decision is measured against it. If a plugin costs 200 KB to save an hour of build time, that is a conversation, not an assumption.

• LCP and INP targets set per template before development starts
• Images served in modern formats at the size they actually render
• Third-party scripts audited and deferred where they are not critical
• Caching and CDN configured as part of the build, not bolted on later

WooCommerce, when you are actually selling

WooCommerce is the right call for most catalogues under a few thousand SKUs where you want full control of the template and the checkout. It stops being the right call when you need complex multi-warehouse inventory or heavy B2B pricing logic — and we will say so rather than sell the build.

Where we do build it, product page structure gets the same attention as the homepage: schema markup, image handling, review display and a checkout that does not lose people at the shipping step.

Headless, and when it is not worth it

Headless WordPress is genuinely better for some projects and pure overhead for most. It costs more to build, more to maintain, and removes the live preview your editors expect. It pays off when you are serving multiple front-ends from one content source or you need rendering performance a well-tuned classic build genuinely cannot reach.

We have written up the decision in full, because it is the question we get asked most often by teams who have been told headless is simply the modern choice.

What happens after launch

Launch is where most builds stop being looked after. Updates and backups are the obvious part; the part that actually protects the investment is monitoring Core Web Vitals against real user data, because a site that passed at handover can fail three months later after a marketing team adds two tags and a hero video.