Custom theme development

Your design, built as a real WordPress theme

A theme coded from your design files — not a purchased theme bent into shape, and not a page builder reproducing your layout at four times the page weight. We also work the other way round, taking a theme you already own and integrating what you actually need into it.

What we build

Design file to theme

Figma, XD, Sketch or layered PSD, built pixel-accurate and responsive. If the design has gaps — and designs usually do at the edges — we flag them rather than inventing answers.

HTML template conversion

A static HTML or Bootstrap template turned into a working theme: real templates, editable content, menus, widget areas, the lot.

Block themes

Modern block themes with a proper theme.json — colours, spacing and type scale defined once so the editor offers your design system instead of every option WordPress has.

Child themes, done properly

So your changes survive the parent theme updating. We’ll also tell you when a child theme is the wrong tool and you’re better off with a small plugin.

Theme integration

You bought a theme and it does 80% of what you need. We build the other 20% without editing core theme files, so updates don’t erase the work.

Getting off the page builder

Rebuilding builder layouts as native templates and blocks. Usually the single biggest performance gain available on an older site.

Block theme, classic theme, or child theme

There are three honest answers and the right one depends on who edits the site after we hand it over, not on which is newest.

  • A block theme when your team will edit layouts themselves. The site editor becomes genuinely usable once theme.json constrains it to your design system — without that constraint it’s a liability.
  • A classic theme when the layouts are fixed and the content is structured. PHP templates with custom fields give editors a form to fill in rather than a canvas to break.
  • A child theme when the parent is well built, actively maintained, and you’re changing appearance and a few behaviours rather than rebuilding.

We ask who will be editing the site in two years before we pick. That question decides more than any technical consideration.

Built in by default

Not extras, and not line items on a quote. These are in every theme we write, because retrofitting any of them costs more than doing it once:

  • No jQuery dependency unless something genuinely needs it
  • Assets enqueued conditionally, so a page loads only what it uses
  • System fonts by default, and web fonts self-hosted when the brand needs one
  • Semantic headings, keyboard focus states and real contrast ratios
  • Translation-ready, and tested right-to-left when that’s in scope
  • Template parts and block patterns, so editors reuse rather than rebuild
  • Editor locking on structural layout, so copy can change and the design can’t break
  • Documentation of what’s custom, written for the next developer

How a theme build runs

We read the design properly first

Every state, every breakpoint, and the pages that weren’t designed — search results, 404, an archive with one item in it, a post with no featured image. That list goes back to you before anything gets built.

Content model before pixels

What’s a post type, what’s a taxonomy, what’s a custom field, what’s a block. Getting this wrong is the thing that makes a site unmaintainable later, and it’s invisible in a design file.

Build on staging, with your real content

Not placeholder text. Real content is what exposes the layout that only works with exactly 40 characters in the heading.

Review against the design, on devices

You compare the build to your own design file. We fix what doesn’t match, and tell you where the design and the browser genuinely disagree.

Handover with the source

The theme, the build files, and documentation. It’s yours — no licence, no phone-home, nothing that stops another developer picking it up.

Which of our pages you actually want

These four overlap in most agencies’ service lists, so here’s the plain version of what sits where:

This page — custom theme development

You have a design, or a theme you own, and you need the theme layer coded. The content and the site already exist, or someone else is handling them.

WordPress development

The whole site: a new build, a rebuild, a theme migration off something bloated, or ongoing work on an existing WordPress install.

Website design & development

You don’t know which platform yet. Start here — WordPress, Shopify, Magento and React compared against what you’re actually building.

Plugin development

Functionality rather than appearance. If it should keep working after you change theme, it belongs in a plugin, and we’ll say so.

Common questions

We don’t have a designer. Can you design it too?

Yes, though it’s worth separating the two conversations. Plenty of projects don’t need a bespoke design at all — a well-chosen theme, properly integrated, gets there faster and cheaper. We’ll tell you which situation you’re in before you commit to a design budget.

Will our team be able to edit it?

That’s decided at the start, deliberately. We can build a theme where editors control layout freely, or one where they fill in structured fields and can’t break the design. Both are valid; the mistake is not choosing and ending up with the worst of each.

Can you work on a theme we already paid for?

Routinely. The important part is doing it without editing the theme’s own files, so an update doesn’t wipe the work — a child theme, a small plugin, or hooks, depending on what’s being changed. If the theme is built so badly that it can’t be extended cleanly, we’ll say so rather than layering fixes onto it.

Is a custom theme slower or faster than a page builder?

Substantially faster, and it isn’t close. A builder ships its own CSS, its own JavaScript and a deep wrapper structure on every page whether a page uses it or not. A custom theme loads what the page needs. The trade is flexibility: you get a faster site that needs a developer for structural changes.

Do you build for WooCommerce too?

Yes — product, category, cart and checkout templates, which are their own discipline rather than ordinary theme work. More under WooCommerce development.

What if we want to change developers later?

Then you can. You get the full source and documentation, the theme uses standard WordPress patterns rather than a private framework, and nothing in it depends on us continuing to exist. We’d rather you stay because the work is good.

Send us the design file

Or the theme you’re stuck with. We’ll tell you what it takes to build properly, what’s missing from the design, and whether a custom theme is even the right answer for you.