01
Custom themes
A theme written for your designs and your content model — no page-level settings panels, no unused layout engine. Templates that render what the page needs and nothing else.
Custom WordPress development, engineered for performance and scale
Bespoke themes, plugins and Gutenberg blocks, written for your content model.
HOW MUCH Labs builds WordPress sites the way software gets built: version-controlled code, a deliberate data model, and only the markup the page actually needs.
The result is a site your editors can run, your developers can read, and your traffic cannot break.
Markup a browser has to render
Generated wrappers
<div class="wrap"><div class="row"><div class="col"><div class="inner"><div class="widget"><h2>Heading</h2>
↓ same heading, hand-built
Semantic template
<section class="intro"><h2>Heading</h2>
The principle
A website is software. It deserves the same engineering discipline.
Most WordPress performance problems are not caused by WordPress. They are caused by layers of generic tooling doing work that a purpose-built template would never do at all.
We start from the content model instead of the layout: what the entities are, how they relate, what editors need to change, and what the site must still do at ten times the traffic.
Then we write only the code that model requires.
Everything lives in Git, runs through code review, and deploys the same way twice. Nothing about the site's behaviour is trapped in a database field only one person understands.
What we build
Every engagement is some combination of these. We scope the ones your project actually needs.
02
Custom plugins
Business logic where it belongs: in a versioned plugin with its own settings, tests and update path, so it survives a theme change.
03
Gutenberg blocks
Purpose-built blocks that give editors real flexibility inside strict design constraints, with sensible defaults and previews in the editor.
04
API integrations
CRMs, ERPs, PIMs, booking and payment systems — connected server-side with caching, retries, error handling and logging you can inspect.
05
Content modelling
Custom post types, taxonomies and fields designed around your entities, so content is structured, queryable and reusable rather than trapped in page copy.
06
Migrations
Moving off a legacy site or another CMS, with content mapped, redirects preserved and search rankings protected.
Performance
Core Web Vitals are a consequence of architecture, not a plugin you install
A caching plugin can hide a slow page. It cannot make a heavy one light. If the template ships megabytes of CSS for a layout that needed a grid, no amount of caching fixes the experience on a phone on mobile data.
We work on the causes instead: what queries run, how many assets load, what blocks the main thread, and what the browser has to lay out before it can paint.
Each of the three Core Web Vitals maps to concrete decisions we make while building — not to a score we chase afterwards.
LCPLargest contentful paint
The main element renders early
Critical CSS inline, hero media sized and prioritised, fonts preloaded with a metric-compatible fallback, and no render-blocking script above the fold.
INPInteraction to next paint
Interactions answer immediately
Little JavaScript to begin with, split by route, deferred where possible — so the main thread is free when a visitor taps something.
CLSCumulative layout shift
Nothing jumps while loading
Explicit dimensions on media and embeds, space reserved for anything injected late, and no content that arrives after the first paint and pushes the page around.
Scalability
Built to hold up when the traffic arrives
Scaling WordPress is mostly about making sure the expensive work happens rarely, and never while a visitor is waiting.
Query discipline
Expensive meta and taxonomy queries replaced with indexed lookups and pre-computed values, so a busy archive page does not fall over.
Caching layers
Object cache for repeated queries, full-page cache for anonymous traffic, and clear rules for what is never cached.
Work moved off the request
Imports, feeds, image processing and third-party calls handled by queued background jobs instead of during a page view.
Media handling
Responsive sizes generated deliberately, modern formats served, and assets delivered from a CDN close to your visitors.
Traffic spikes
Behaviour under load tested before launch, not discovered during a campaign — with cache warming and sensible rate limits.
Security & hardening
Least-privilege roles, dependency updates through the repository, secrets kept out of the codebase, and an audit trail of deployments.
WordPress as the editing layer, something else as the front end
Your editors keep the admin they already know. The public site is rendered by a framework of its own — statically generated, or server-rendered on demand — reading content over REST or GraphQL.
It suits sites with several front ends, an app that shares the same content, or a front end whose interactivity has outgrown a PHP template.
It also costs more to build and operate than a well-made theme. We will tell you when you do not need it.
When it earns its keep
Several front ends sharing one content source
A mobile app reading the same content as the site
A highly interactive front end that has outgrown PHP templates
A front-end team that works in a JS framework already
Content that must be published to a static host
A marketing site that a well-built theme would serve better
A small team, where two codebases means twice the maintenance
WooCommerce
Stores that stay fast with a large catalogue and a busy checkout
WooCommerce is where custom development pays for itself fastest. Catalogue pages, cart and checkout are the three places a generic setup starts to hurt — and all three are ordinary engineering problems.
Product archives get real indexes and cached facets instead of expensive meta queries. Cart and checkout stay uncached and lean, so the pages that carry revenue are the pages doing least work.
On top of that: custom pricing rules, B2B tiers and quotes, subscriptions, ERP and stock synchronization, payment and shipping integrations, and the reporting your finance team keeps asking for.
Catalogue & checkout at scale
Catalogue · thousands of products
↓ indexed facets · object cache
Filtered archive · served from cache
In stockSize M€50–100
↓ session-aware · never page-cached
Cart & checkoutMinimal assets
Payment, stock and tax logic isolated in a custom plugin, testable on its own.
How a WordPress project runs with us
1
Discovery and technical audit
We start with what the site has to achieve, who edits it, and what systems it must talk to.
For an existing site we audit the theme, plugins, data model, hosting and performance first, so the plan addresses causes rather than symptoms.
2
Architecture and content model
Before any templates are written we agree the content model: post types, taxonomies, fields, relationships and the editing experience around them.
This is also where we decide what the site does not need — usually the most valuable decision in the project.
3
Build in reviewable slices
Development happens in branches, with code review and coding standards enforced.
You see working pages on staging as they land, not a single reveal at the end. Feedback arrives while it is still cheap to act on.
4
Testing and launch
Performance, accessibility, cross-browser behaviour and editor workflows are checked on staging, against production-like data and hosting.
Launch is a deployment of a reviewed commit, with redirects in place and a rollback path if anything looks wrong.
5
Handover and aftercare
You receive the repository, documentation, and a walkthrough for whoever maintains and edits the site.
From there we can stay on for maintenance and further development, or step back entirely — the codebase is written to be readable either way.
Stack & tooling
Everything through Git, nothing edited on production
A change is written locally, reviewed, tested on staging, then released. The same commit that passed staging is the one that goes live.
WordPresscustom themes · plugins · blocks
PHPmodern PHP · Composer · PSR standards
Front endTypeScript · Vite · progressive enhancement
DataMySQL · Redis object cache
Local & CIDocker · Git · automated checks
InfrastructureAWS · Azure · CDN · monitoring
Deployment pipeline
LocalDocker
Same PHP & MySQL as productionSeeded contentLinting on commit
Pull request · code review
StagingProduction-like
Automated checksClient reviewPerformance & a11y pass
Reviewed commit · deploy
ProductionLive
Zero-downtime deployRollback pathUptime & error monitoring
After launch
Maintenance and support, with the code left readable on purpose
Custom code is only an asset if someone can pick it up later. We document what we build and hand over a repository your own team — or your next developer — can work in.
Core, plugin and dependency updates
Applied on staging first, with the site's own test pass before anything reaches production.
Monitoring and error tracking
Uptime, errors and slow queries reported to us, so problems surface before your visitors report them.
Backups and recovery
Database and media backed up on a schedule, with a restore that has actually been tested.
Performance reviews
Periodic checks that field metrics have not drifted as content and traffic grow.
Ongoing development
New features handled as small scoped changes through the same review-and-deploy pipeline.
Documentation and handover
Architecture notes, editor guides and deployment instructions kept in the repository, current at the point we hand over.
For agencies & studios
We build behind your name, quietly
You own the client relationship and the design. We take the build — theme, plugins, integrations — and deliver it in your repository, to your coding standards.
White-label by default: no badge in the footer, no contact with your client unless you want us in the room.
Works as a fixed-scope build or as ongoing capacity when your own team is full.
For companies
A build you are not locked out of
Starting a new site, or replacing one that has become slow and fragile — we scope the content model with you first, so the build reflects how your business actually works.
You get the repository, the documentation and the deployment setup. No proprietary layer, no licence that stops working when we stop.
If part of the existing site is worth keeping, we keep it rather than rebuilding for its own sake.
In production
What this looks like on a real build: WordPress and Zabun
Our real-estate work is the clearest example of custom WordPress development on this site: a bespoke plugin syncing a property CRM into WordPress, custom post types and taxonomies, indexable filter URLs, scheduled jobs, and enquiries posted back into the CRM.
Same engineering, different domain. If you have an external system that needs to drive your website, the shape of the problem is the same.
Read the Zabun integration pageCustom plugin · what it does
Property data pulled from the CRM API on a schedule
Mapped into custom post types, taxonomies and ACF fields
Media synchronised locally instead of hot-linked
Filter combinations exposed as indexable, SEO-friendly URLs
Website enquiries posted back into the CRM, attached to the property
FAQ
Frequently asked questions
Something specific about your setup? Describe it and we'll tell you what we would do.
An off-the-shelf theme is built to fit every site, so it carries features and markup yours will never use. A custom theme contains only your content model and only your layouts, which is why it stays fast and stays easy to change.
Yes — that is the point of building on WordPress at all. We give editors a small set of purpose-built blocks and fields that match your page designs, so the pages they produce cannot drift away from the design system.
Often. We start by auditing the current theme, plugins, data model and hosting, then propose either a targeted rebuild of the slow parts or a full custom theme, depending on what the audit finds.
You do. Everything is delivered in a Git repository you control, with documentation and the deployment configuration. There is no proprietary layer that stops working if you stop working with us.
Yes. We review what exists, document it, and work from there. If parts of it are worth keeping, we keep them.
Yes — distributable plugins with proper settings, update handling, internationalisation and coding standards, whether for one client or for release.
We work with your host or advise on one. What we require is unremarkable: PHP-FPM, an object cache, HTTP caching, cron that is actually reliable, and a staging environment that matches production.
Part of it. A WooCommerce store is custom WordPress development with commerce constraints attached — the catalogue, cart and checkout sections above describe how we approach it.
Start a project
Tell us what the site has to do
A new custom build, a rebuild of something that has become slow, a plugin that needs writing properly, or dev capacity behind your agency — describe the situation and we'll come back with an approach and a scope.
If a custom build is not the right answer for your project, we'll say so.