Web & Conversion
WordPress development
WordPress development done properly means a custom theme, structured editable fields and a short plugin list. No page builder, no thirty-plugin stack nobody can explain, and no site that gets slower every time someone adds a section.
- No page builders
- Editable without a developer
- Your repository
Sound familiar
How WordPress sites decay
Nobody dares update anything in case it breaks.
There are nineteen plugins and four of them do the same thing.
The homepage is one enormous page builder block.
Why WordPress sites get slow and fragile
WordPress is not slow. WordPress sites are slow, and almost always for the same three reasons.
The first is page builders. They ship large CSS and JavaScript bundles to render layouts that need very little of either, they nest markup several levels deeper than necessary, and they store content as serialised markup rather than as data, which makes it painful to migrate later. The convenience is real. So is the permanent cost.
The second is plugin sprawl. Each plugin arrives with its own stylesheet, its own script and its own database queries, loaded on every page whether needed or not. Twenty plugins is not twenty times one plugin, it is a compounding tax on every request and a growing surface area for conflicts.
The third is that content lives in markup instead of in fields. Once a headline is embedded in a blob of builder HTML, you cannot change the design without rewriting content, and you cannot reuse the content anywhere else.
How I build instead
A custom theme, hand-written
Templates written for the site rather than a general-purpose theme configured into submission. The CSS is the CSS the site needs. The JavaScript is the small amount genuinely required, loaded as modules and deferred. Nothing is shipped for a feature you are not using.
That is not craft for its own sake. It is the difference between a page weighing a few hundred kilobytes and one weighing several megabytes, and on a mid-range phone that is the difference between usable and abandoned.
Structured content in labelled fields
Every editable thing gets a proper field with a clear label: headline, body, image, link, each in its own place. Editors change content without touching markup, and the same content can be presented differently on different templates or exported elsewhere.
This is also what makes a redesign affordable later. When content is data rather than markup, a new design is a new set of templates rather than a re-entry project.
A short, justified plugin list
Some plugins are worth their weight: a good field framework, a security layer, a backup system, a caching layer if the hosting does not provide one. Most are not, and half of what plugins are typically installed for is twenty lines of theme code that loads nothing extra.
Every plugin on a site I build has a reason I can state. If I cannot, it goes.
Performance held to a budget
An agreed limit on CSS, JavaScript and third-party scripts, enforced during the build rather than measured afterwards. Third-party scripts are the usual culprit: a tag manager, three analytics tools, a chat widget and a heat mapper will undo every optimisation underneath them. I will tell you what each one costs in milliseconds so the decision is informed.
Maintainability
Code in a repository, not edited through the admin. Documentation aimed at whoever maintains it next. A staging environment. An update process that is safe to run. The measure of a good build is whether a competent developer who has never met me can pick it up in an afternoon.
Migrating away from a page builder
This is common and it is worth doing carefully. Content has to be extracted from builder markup into structured fields, which is part automated and part manual. URLs must be preserved. Redirects must be mapped and tested before launch.
It is more work than a fresh build and usually worth it, because you keep your search visibility and your content history rather than starting again.
What you get
Included in every WordPress build
-
Hand-written custom theme
Templates written for your site. The CSS is the CSS the site needs, the JavaScript is the little that is genuinely required.
-
Content as structured fields
Every editable thing in a labelled field, so editors never touch markup and a future redesign is templates rather than re-entry.
-
A short, justified plugin list
Every plugin has a reason I can state out loud. Anything that is twenty lines of theme code becomes twenty lines of theme code.
-
Enforced performance budget
Agreed limits on CSS, JavaScript and third-party scripts, with the cost of each tracking script stated in milliseconds before you approve it.
The process
Content model, then templates
-
Model the content
What each page type contains, what must be editable and what should be reusable. Before any template exists.
-
Build to budget
Custom templates, structured fields, short plugin list, performance checked as we go rather than at the end.
-
Launch and hand over
Redirect audit, field data check, accessibility pass, documentation and a walkthrough for your team.
Questions
WordPress development questions
Why not use a page builder? Our team likes ours.
Because the convenience is paid for on every page load, forever, and because content stored as builder markup is expensive to redesign or migrate later. Structured fields give editors the same day-to-day control without either cost. If your team specifically wants free-form layout control, say so early and we will design the field structure around that.
Can you rescue an existing site instead of rebuilding?
Often, and it is usually cheaper. A plugin audit, a performance pass and fixing the two or three worst templates recovers most of the benefit at a fraction of the cost. I will always cost the repair before the rebuild and tell you honestly which is better value.
Is WordPress still the right choice?
For most content and marketing sites, yes. The editing experience is familiar, the hosting is inexpensive and the ecosystem is enormous. It is a poor choice when you need a genuine web application, and in that case I will tell you rather than bending WordPress into a shape it resents.
Who owns the code?
You do, in your repository, on your hosting, from the first commit. No proprietary framework, no licence that expires, nothing that stops working if we part ways.
Next step
Repair or rebuild?
Send me the URL. I will tell you which one your site needs and roughly what each costs. Repair is often the answer and I will say so when it is.
- Reply within 24h
- Repair costed first
- You own the code