A look back, written in 2026. For a long stretch of my freelance years, WordPress was most of the work — themes, plugins, migrations, and the phone call that starts with “the site is down”.
Developers are sniffy about it. I am not, because the platform taught me things that framework work never would have.
Clients do not want a website
They want enquiries, or bookings, or to stop looking small next to a competitor. The site is the means. I learned this by watching people accept a beautiful build without enthusiasm, and light up when the first enquiry came through the form.
Once you have seen that a few times, you stop opening a project by talking about the design and start by asking what a good week looks like: how many enquiries, from whom, about what.
The four pages that do the work
On a small firm's site the traffic almost always concentrates on the home page, one service page, the about page and the contact page. Everything else exists for completeness. Clients who insist on thirty pages are usually describing their internal structure, not their customers' questions.
The most useful thing I do early in a project now is ask which pages someone would have to read to decide to call. It is rarely more than four.
A page that nobody can find, nobody reads and nobody maintains is not an asset. It is a small liability that makes the useful pages harder to find.
Maintenance is the product
WordPress taught me this by making it unavoidable. Plugins update, PHP versions move, and something breaks while you are asleep. A site is not a delivery, it is a commitment — and if you hand a client something that needs monthly care without telling them, you have set them up to fail.
It is why I now quote maintenance separately and plainly, rather than pretending a build is finished when the invoice is paid.
Where it stopped fitting
The break came when a project needed things WordPress can do but resists: custom data, a real workflow, an interface for staff who are not editors. You can force it, and I have, and the result is a stack of plugins nobody wants to inherit.
Now the question I ask is whether the content is pages, or data. Pages are what WordPress is good at. Data — courses, enrolments, bookings, anything with rules about who may see what — is where a bespoke build earns its money.
What I kept
Two habits. First: give a client an editor they can actually use, with the fields they need and none they do not. Half of WordPress's plugin economy exists because the default editing experience was not shaped around any particular job.
Second: write the copy before the design. Every project that went smoothly had the words first. Every project that dragged had a beautiful layout waiting for text that nobody had been asked to write.
That second habit is the single biggest predictor of whether a website project finishes on time, and it has nothing to do with the platform.
