WORDPRESS · WOOCOMMERCE · BUILT BY HAND

WordPress that does not need thirty plugins to work.

Most WordPress sites we inherit are not badly built exactly. They are accumulated. A page builder, then a second page builder for the parts the first one could not do, then plugins to fix what those two broke, and by year three nobody can update anything without something going dark.

We build WordPress the way it is meant to be built: a custom theme from a design system, plugins written only where nothing suitable exists, and a stack short enough that a security update is a Tuesday afternoon rather than a project.

Working with us as an agency? See white-label WordPress

Discuss a WordPress project See what we have built
TWO KINDS OF WORK
NEW BUILDS
  • Custom themes from a design system
  • Custom plugins where needed
  • WooCommerce stores
  • Multilingual with WPML or Polylang
  • Migrations from other platforms
EXISTING SITES
  • Taking over undocumented builds
  • Untangling plugin conflicts
  • Performance and database cleanup
  • Security hardening and patching
  • Monthly maintenance retainers
What we build

Six areas, and what each involves.

WordPress covers everything from a five-page brochure to a store doing serious volume. This is the work we take on.

01

Custom themes

Built from a design system so the site still looks right when an editor makes a page nobody designed, using the block editor or ACF rather than a builder plugin.

  • Block editor patterns and custom blocks
  • ACF field groups for structured content
  • Child theme structure so updates survive
  • Accessibility to WCAG AA where required
02

Custom plugins

Written to WordPress coding standards with proper hooks, capability checks and sanitisation, so they behave when the next plugin arrives.

  • Custom post types and taxonomies
  • Admin screens editors can actually use
  • REST endpoints for integrations
  • Uninstall routines that clean up after themselves
03

WooCommerce

Store builds and the parts that get complicated once a catalogue grows past the point where defaults hold up.

  • Payment, shipping and tax configuration
  • Custom product types and variable pricing
  • Checkout customisation and B2B pricing
  • ERP, PIM and fulfilment integrations
04

Migrations

Moving into WordPress from another platform, or moving a WordPress site to new hosting without losing what it already earns.

  • Content, media and user migration
  • URL structure and redirect mapping
  • SEO metadata carried across
  • Verification against the source before cutover
05

Performance

WordPress is fast or slow depending on what has accumulated in it. The work is usually removal rather than addition.

  • Object and page caching configured properly
  • Database cleanup: revisions, transients, orphans
  • Image sizing, formats and lazy loading
  • Auditing plugins for injected weight
06

Security and maintenance

Most WordPress compromises come through an abandoned plugin rather than through core. Keeping the surface small is most of the job.

  • Core, theme and plugin patching on staging first
  • Removing abandoned and duplicated plugins
  • Hardening logins, permissions and file access
  • Backups that are restored and verified
Inherited sites

A large share of what we do is other people’s WordPress.

Nobody plans to hand a site to a new developer. It happens when someone leaves, an agency relationship ends, or a build stalls. These are the states we usually find.

The plugin graveyard

Forty plugins installed, twelve doing nothing, three abandoned by their authors and one of those holding an unpatched vulnerability. The audit lists what can go, what must be replaced, and what has to stay.

The theme edited in place

Changes made directly in a purchased theme rather than a child theme, so every update wipes them and the site has not been updated in two years. The fix is extracting the changes into a proper child theme first.

The site nobody has credentials for

Hosting, domain, admin and the developer’s own account all in different hands, and one of them unreachable. Tedious rather than technical, but it has to happen before anything else can.

The half-finished build

A project that stalled with the developer gone. We audit what is done, what is stubbed and what only appears finished, then give you an honest choice between continuing and restarting.

Our approach

Fewer moving parts, on purpose.

A short plugin list

Every plugin is a dependency, a security surface and a future update conflict. We use them where they earn their place and write a small amount of code where three plugins would otherwise be needed.

Standards and tooling

WordPress coding standards enforced with PHPCS, escaping and sanitisation on output and input, and capability checks on anything privileged. Enforced by tooling so it is not a matter of memory.

Version control and staging

The theme and custom plugins live in Git, and updates are tested on staging before production. If a site arrives without either, setting them up is usually the first thing we do.

Documentation for whoever is next

What the custom code does, why each plugin is installed, and how to deploy. Written for a developer who has never spoken to us, since eventually that is who reads it.

Questions

What clients ask about WordPress work.

Do you use page builders like Elementor or Divi?
Only when a client already has one and wants to keep it. For new builds we use the block editor or ACF with a custom theme, because page builders add weight, lock content into proprietary markup, and make the site hard to move later. If you inherit a builder site from us, you will not need our permission to change anything.
Can you take over a WordPress site somebody else built?
Yes, and it is a large share of what we do. It starts with an audit: what plugins are installed and which are abandoned, whether the theme is a child theme or has been edited directly, what is in the database that should not be, and where the security exposure is. You get that written up before anyone commits to ongoing work.
Our site broke after an update and nobody knows why. Can you help?
Usually yes. The common causes are a plugin conflict, a theme edited in place so an update wiped the changes, or a PHP version jump the code was not ready for. The fix is normally quick once the cause is identified, and the useful part afterwards is setting up staging so the next update is tested before it reaches production.
Do you build custom plugins or use existing ones?
Existing first, when a well-maintained one does the job. A plugin with an active developer and a security process is safer than bespoke code only we understand. We write custom plugins when nothing suitable exists, when the alternative is installing three plugins to do one job, or when a client needs functionality that should not depend on a third party.
Can you do WooCommerce?
Yes, including the parts that get awkward: custom product types, variable pricing, subscription flows, tax and shipping rules across regions, and integrations with ERP or fulfilment systems. Stores that were fine at two hundred products and struggle at two thousand are a common brief, and that is usually a database and query problem rather than a hosting one.
How do you handle multilingual WordPress?
WPML or Polylang depending on the requirement and the budget, with the translation workflow agreed before the build rather than added afterwards. Retrofitting multilingual onto a finished site costs several times what building for it costs, so it is worth deciding early even if translations come later.
Can you improve WordPress performance?
Yes, and it is rarely one thing. Typical causes are uncached queries, an oversized database full of revisions and transients, images served far larger than displayed, render-blocking scripts injected by plugins, and hosting that is cheaper than the site needs. The audit tells you which of those apply to you, in order of impact.
Do you offer WordPress maintenance?
Yes, on monthly retainers. Core, theme and plugin updates tested on staging first, security patching, uptime monitoring, backups that are actually restored and verified rather than assumed, and a set amount of small feature work each month.
Can WordPress be used headless?
It can, with the REST API or WPGraphQL feeding a React or Next.js front end. It is worth it when the content feeds several channels or the front end needs to do things a theme cannot. For a standard marketing site it usually adds cost and complexity without adding value, and we will say so.
Do you work white-label for agencies on WordPress?
Yes. We work inside your repository and process, and your client deals only with you.
Get in touch

Send us the site, however it looks under the bonnet.

A URL, admin access, or a description of what keeps breaking. Within one working day you get a reply from the engineer who would do the work.

Before anything is signed, you get a written technical assessment: the real scope, where the risk sits, what we would build differently and why, and a fixed price against it. It costs nothing and it is yours to keep either way.

Reply within one working day, from an engineer Free written technical assessment Fixed scope and price before you commit
Request a technical assessment WhatsApp

Related

WHITE LABEL White-label for agencies How we work under your brand, inside your repository and process. DRUPAL Drupal development Custom modules, theming, multisite, integrations and performance. AI AI integration LLM features built into the platform you already run.