[ WordPress  /  WordPress Development ]

WordPress built by someone who writes the code.

Not a theme bought from a marketplace and wrestled into shape. Custom work that loads fast, updates safely and that your next developer can read without cursing.

Fixed scope · Staging site included · You own the code

Customcode, not a bought theme
Stagingenvironment included
You owneverything, no lock-in
Fixedscope and price

[ Why teams call ]

What I get asked to replace.

Most WordPress pain is not caused by WordPress. It is caused by how the site was assembled.

Page-builder sprawl

Thirty plugins layered on a marketplace theme, where nobody can change a heading without breaking a layout.

Painfully slow

Megabytes of unused CSS and JavaScript loaded on every page because the theme ships every feature it has ever offered.

Nobody can maintain it

Custom work done directly in a theme that gets overwritten by its next update.

Integrations glued on

A payment or CRM connection held together by a snippet plugin and nobody remembers where it lives.

Editors are afraid of it

The content team cannot publish without help, so the CMS is doing none of its job.

Locked into a platform

Content trapped in proprietary shortcodes that mean nothing outside the theme that created them.

[ How it works ]

Scope, build, hand over.

01  —  Week 1

Scope

What the site must do, who edits it and what it integrates with. You get a written scope, a fixed price and a delivery date before development starts.

02  —  Week 2-5

Build

Built on a staging site you can watch progress on, with editable content structures rather than hardcoded layouts.

03  —  Launch

Ship & train

Launch with redirects verified, performance checked, then a walkthrough so your team can actually run it.

[ What actually changes ]

How I build.

The goal is a site your content team can operate without me and your next developer can extend without a rewrite.

Build quality

  • Custom theme — only the code your site needs, so pages are small and fast by default.
  • Structured content — proper fields and post types, not formatting instructions buried in the body.
  • Block editor support — editors compose pages from components that cannot break the design.
  • Version-controlled code — in your repository, deployed by pipeline, never edited on the live server.
  • WooCommerce where needed — product, checkout and payment work without a plugin for every field.

Handover

  • Performance budget — Core Web Vitals checked before launch, not diagnosed afterwards.
  • Accessibility pass — keyboard navigation, contrast and semantics checked as part of the build.
  • SEO foundations — clean markup, structured data, sane URLs and a working redirect map.
  • Editor documentation — short written guides for the people who publish, not just for developers.
  • Staging environment — so future changes are tested somewhere that is not your live site.

[ Example engagement ]

Marketplace theme replaced with a custom build.

A content site on a heavy multipurpose theme with twenty-eight plugins. Rebuilt as a custom theme with structured content and a component-based editor experience.

Illustrative example of a typical engagement. Figures vary with the state of your systems and are not a guarantee of a specific outcome.

71%smaller page weight
28 to 6plugins remaining
2.4sfaster largest paint
0developer needed to publish

[ Free · no obligation ]

Get a scope and a real number.

Describe what you need the site to do. You get a written scope, a fixed price and a delivery date, with no sales sequence attached.

Get a scope

[ Pricing ]

Pricing that fits your budget.

Tell me the number you have to work with. I'll tell you honestly what's achievable within it — and if it isn't enough, I'll say so before we start rather than halfway through.

Fixed project price

Scope agreed in writing, price agreed in writing, before any work starts. No hourly creep and no invoice you haven't already approved.

Monthly retainer

For ongoing work — maintenance, monitoring, updates and small changes. Month to month, cancel whenever, no minimum term.

Hourly for small jobs

For a single bug or a short task where writing a full scope would cost more than simply doing the work.

Budget too tight for the whole thing? I'll often suggest doing the highest-value part first and the rest later, rather than doing all of it badly.

[ Questions ]

Common questions.

Do you use page builders?

Only when a client already depends on one and replacing it is not worth the cost. For new builds I use the native block editor with custom blocks, which gives editors flexibility without the performance and lock-in penalty.

Can you work on our existing site?

Yes. A good part of my WordPress work is improving sites someone else built. I will tell you honestly when a rebuild would cost less than continuing to patch what is there.

Is WordPress still the right choice?

For content-led sites with non-technical editors, very often yes. For a web application with complex logic and user accounts, a framework like Laravel or Next.js is usually the better fit, and I will say so rather than sell you the wrong thing.

Who owns the code?

You do, completely. It lives in your repository, uses no licensed components you cannot renew, and any competent WordPress developer can pick it up.

Do you do maintenance afterwards?

Optionally, as a monthly retainer covering updates, backups, monitoring and small changes. Plenty of clients handle it in-house instead, which is a perfectly good outcome.

[ Let's talk ]

Tell me what you're building.

Describe it in a few lines and you'll get a straight answer on scope, cost and timeline — same working day, from the person who'd actually build it.