There is something pleasing about an engine house
Cornwall is full of buildings that seem to have no business still being there.
Old engine houses sit on exposed hillsides and cliff edges, taking weather that would make a modern garden fence reconsider its life choices.
Some are ruined. Some are preserved. None is indestructible.
But the ones that remain make a fairly obvious point: foundations and materials matter.
Websites are less romantic, admittedly.
Nobody is going to put your caching layer on a postcard.
But the principle still applies.
A website can look beautiful in a design review and still be badly built underneath. You only discover that later, when the connection is poor, traffic increases, a dependency fails, an update breaks something or a customer tries to use the site on an ordinary phone rather than the designer’s enormous monitor.
That is usually when the decorative decisions become less interesting.
Fast is not the same as finished
I care quite a lot about speed, but not because a website needs to win some kind of internet drag race.
Speed is part of whether the thing works.
A slow booking page creates doubt.
A sluggish checkout creates friction.
A page that jumps around while loading makes it harder to use.
A form that silently stops working because a script failed is not a minor technical detail. It is a broken front door.
Core Web Vitals and other performance measures are useful because they give us ways to measure parts of that experience.
They are not the experience itself.
A perfect score does not make a bad website good, and a slightly imperfect score does not make a useful website worthless.
The numbers are there to help diagnose the building.
They are not the building.
Bloat rarely arrives in one dramatic moment
A slow site does not need one outrageous decision to get that way.
They get there gradually.
A plugin for this.
A tracking script for that.
A page builder extension.
A chat widget.
Another font.
A third-party review badge.
A video loading where a still image would have done the job.
Individually, each addition is defensible.
Collectively, the site begins to feel like somebody has furnished a studio flat using the entire contents of IKEA.
This is why I am wary of technical stacks that grow without somebody periodically asking whether each part still needs to exist.
Not every plugin is bad.
Not every page builder is bad.
Custom code is not automatically virtuous either. Poorly written bespoke software can be far worse than a boring, well-maintained WordPress site.
The question is simpler:
What does this thing add, and what does it cost?
Choose boring infrastructure where boring is useful
There is a tendency in web development to become excited about the clever bit.
I understand this because I do it too.
A new framework is interesting. A new architecture is interesting. A complicated integration can be very satisfying when it finally works.
The customer, however, is generally not paying for our personal enrichment.
They want the site to load.
They want the enquiry to arrive.
They want the booking to go through.
They want it to keep working next month.
So I am quite happy for infrastructure to be boring.
Good hosting.
Caching that is actually configured.
Images that are sensibly sized.
Dependencies kept under control.
Backups that can be restored.
Monitoring that tells you when something has failed.
Forms that are tested rather than admired.
Exceptionally unsexy.
Also useful.
Build so one failure does not become everybody’s problem
Another part of resilient architecture is deciding what should happen when something else fails.
If an analytics service is unavailable, should the website stop working?
No.
If a social-media embed has a bad day, should the booking form disappear?
Preferably not.
If one external integration fails, can the core business still operate?
The more your site depends on third parties, the more important this becomes.
Decoupling does not mean making everything needlessly complicated. Often it means the opposite: keeping the important path simple enough that optional extras can fail without taking the business with them.
WordPress, headless, custom — I genuinely do not care
There are people who become emotionally attached to stacks.
I do not think customers should have to fund that argument.
WordPress can be excellent.
WordPress can also be an archaeological site containing fifteen years of plugins and decisions nobody remembers making.
A headless site can be extremely fast and well structured.
It can also be unnecessary complexity for a five-page local business website.
The right architecture is the one that fits the actual job.
What needs to be edited?
Who needs to edit it?
What integrations matter?
How much traffic is realistic?
What happens if I disappear tomorrow and somebody else has to maintain it?
Those questions are much more useful than choosing technology because it looked impressive in a case study.
Granite is not glamorous either
That is why the Cornwall comparison works for me.
The point of granite is not that it is fashionable.
It is that, used properly, it is dependable.
A business website should have the same quality.
You should be able to change the branding without rebuilding the foundations.
You should be able to add content without wrecking performance.
A marketing campaign should not expose a site that only functioned because nobody had visited it yet.
Build the boring parts properly.
Then make it beautiful.
Not the other way round.