WordPress & WooCommerce
Custom WordPress, written by hand. No page builder.
I build WordPress themes, blocks and plugins the way you would build any other application: in a repository, in PHP you can read, with a build step and a handover document. Twelve years of it, mostly for agencies and businesses who inherited something slow and want to stop renewing licences.
With a page builder
Builder CSS, builder JS, an icon font, the theme and its add-ons — every one of them before the first word appears.
Written by hand
One stylesheet. Then the page.
01ScopeWhat I build
What a WordPress build actually includes.
Custom themes from a design
A theme written for your design and nothing else. Templates in PHP, styles in CSS you could hand to another developer, and a build step that produces one stylesheet and one script rather than the twenty-odd requests a builder stack usually emits. If you have a Figma file with a defined type scale and spacing system, that translates almost directly.
Native Gutenberg blocks for your content
Editors do not need a canvas where anything can go anywhere. They need eight or ten blocks that match the things your site actually publishes — a stat row, a case study card, a pricing table, a callout — with the fields filled in and nothing else exposed. Blocks are registered with block.json, so they carry no licence and no runtime dependency.
WooCommerce that survives a busy week
Custom product types, checkout adjustments, shipping and tax rules, payment gateway work, and the unglamorous part nobody quotes for: making sure the cart and checkout are not running a dozen uncached queries on every request. Most slow WooCommerce sites are slow in the database, not the front end.
Plugins for the thing no plugin does
When the requirement is genuinely specific — a booking rule, an ERP sync, an internal approval flow — a small purpose-built plugin is cheaper to own than bending a general-purpose one and maintaining that bend forever.
Rescuing an inherited build
About half this work is a site somebody else made. I will read what is there before quoting, and tell you plainly whether it is worth extending or worth replacing. Sometimes the honest answer is that the existing site is fine and you need three days of work, not thirty.
02PositionWhy it matters to you
Why I don't build with page builders.
This is the question I get asked most, so here is the actual answer rather than a slogan. Page builders are not bad software. They are the right tool for a brochure site that needs to exist by Friday and will never be touched again. They are the wrong tool for a site your business runs on, for four specific reasons.
They ship markup you did not ask for
A builder has to be able to render anything, so it emits deeply nested wrappers around everything, plus the CSS and JavaScript to control them. That weight is on every page, whether or not the page uses the features. It is the most common single cause of a failing Largest Contentful Paint score on sites I am asked to fix.
Your content ends up inside the tool
Builder layouts are stored as encoded shortcodes or serialised data in the database, not as clean post content. Deactivate the plugin and much of your site becomes unreadable markup. That is not a bug — it is the trade you made. It is worth knowing you made it.
They add a licence to your running costs
A builder, its add-ons and the theme it depends on are typically a few hundred dollars a year, forever, to keep receiving security updates. Over the life of a site that is often more than the difference in build cost.
Every editor becomes a designer
Given an unconstrained canvas, well-meaning people produce twelve slightly different button styles. A small set of purpose-built blocks makes the right result the easy result, which is what a design system is for.
If you already have a builder site and it works, I will not tell you to throw it away. I will tell you what it is costing you in load time and licences, and let you decide whether that is worth changing.
03ProcessGenuinely a sequence
How a build runs.
- 01
Read what exists
- Before quoting I look at the current site, the content model and the design. You get a written scope with what is included, what is not, and where I think the risk is — usually content migration or an integration nobody has documented.
- 02
Content model first
- Post types, taxonomies, fields and blocks get decided before any template is written. Changing this later is the single most expensive kind of rework, so it is worth an extra day up front.
- 03
Build on a staging URL
- You get a link you can watch progress on from week one, and a place to leave comments. No month of silence followed by a reveal.
- 04
Migrate, test, measure
- Content moves across, redirects are mapped from the old URLs, and I check Core Web Vitals, accessibility basics and cross-browser behaviour before launch — not after. Old URLs keep working.
- 05
Hand over properly
- Repository, build instructions, a walkthrough of how the theme is structured, and a short video for whoever edits the site. You should not need me for ordinary changes.
04QuestionsAsked often, answered plainly
Things people ask before hiring me.
Do you work on existing sites or only new builds?
Both, and roughly half of it is inherited work. I will read the existing code before quoting and tell you honestly whether it is worth extending or worth replacing. Quoting a rebuild is easy; telling you that you do not need one is more useful.
Can you build from our designer's Figma files?
Yes, and it is the setup I prefer. What makes it go smoothly is a defined type scale, spacing system and breakpoints. What slows it down is the states designers usually leave out — empty, loading, error, and content three times longer than the placeholder. I will ask about those early.
Will my team still be able to edit the site?
Yes. Avoiding page builders is not about taking editing away — it is about giving editors a small set of blocks that always look right, rather than a canvas where anything can be dragged anywhere. Most teams find they can do more, not less, because nothing is fragile.
Do you use ACF or native blocks?
Native block.json blocks by default, because they carry no licence and no runtime dependency. I use Advanced Custom Fields where it genuinely saves time — complex repeatable fields, options pages, relationship fields — and I will tell you which parts depend on it so you know exactly what you are carrying.
Am I locked into you afterwards?
No. You get the repository, the build scripts and a written handover. It is ordinary WordPress and ordinary PHP, so any competent WordPress developer can pick it up. That is the deliberate outcome of not building on proprietary tooling — the code outlives the working relationship.
Do you offer ongoing maintenance?
A small monthly retainer covering updates, monitoring and a fixed block of change work, if you want it. I do not push it. A site built without plugin sprawl needs considerably less maintenance than one that is not, which is rather the point of building it that way.
Where are you, and what does that mean for meetings?
Nagpur, India, on IST. That overlaps comfortably with a European morning and a US East Coast start. I answer email the same working day, and you talk to me directly rather than through an account manager.
Next step
Tell me what you have and what is wrong with it.
A paragraph is enough to start. If WordPress is the wrong answer for your project I will say so — sometimes the honest recommendation is a Laravel application instead.