There was a period in my career when starting a new website involved very little discussion about what it should be built with.
For a huge number of projects, the answer was WordPress.
And there was a good reason for that.
I spent years building websites for businesses around Felixstowe, Suffolk and further afield. A typical client needed pages they could edit, perhaps a blog, some contact forms and a reasonably straightforward way of managing everything without calling me every time they wanted to change a sentence.
WordPress was very good at solving that problem.
It still is.
But the websites I build today increasingly aren't typical client websites.
And that has changed how I decide what sits underneath them.
I Used to Choose the Platform Before the Website Existed
When you're building websites repeatedly for clients, standardisation makes enormous sense.
You learn your platform.
You develop ways of doing things.
You know how you want hosting configured.
You know which problems are likely to appear.
You build your own collection of code, plugins and shortcuts.
Eventually, starting another website becomes incredibly efficient.
If somebody wanted a Felixstowe web design company to build a new business website, they generally didn't care about the technical decisions underneath it.
They cared that it worked.
If they were investing in SEO, they wanted Google to understand it.
If they were paying for Google Ads or PPC, they wanted the landing pages to turn visitors into enquiries.
If they were selling online, they wanted the ecommerce website to take orders.
The platform was my problem.
That made using something familiar a sensible business decision.
Then My Websites Started Doing Stranger Things
The change happened gradually.
I started building more things for myself.
And when you're both the developer and the person with the ridiculous idea, something interesting happens.
You stop having to explain why the website shouldn't work like every other website.
I might want a page generated entirely from database information.
I might want a scheduled process collecting something every hour.
I might want one website feeding information into another system.
I might need a dashboard that only I can see.
I might want content generated from information the system has accumulated over months.
I might need an interface that has absolutely no reason to resemble a conventional WordPress admin screen.
At that point, starting with a traditional content management system and forcing the idea into it can become backwards.
I Started Asking a Different First Question
For years, my first question was effectively:
How am I going to build this website?
Now it is much closer to:
What does this thing actually need to do?
That sounds like a tiny difference.
It isn't.
If the answer is essentially "publish articles and allow somebody to edit pages", WordPress may still be an excellent choice.
If the answer involves collecting data, analysing it, connecting several systems, generating content, maintaining user accounts and running scheduled processes throughout the day, I might make a completely different decision.
The technology comes after the requirement.
Twenty Years Ago, the Website Was Usually the Product
This shift also says something about how much the web itself has changed.
A business website once existed primarily to present information.
You built the pages.
You worked on the web design.
You optimised them for search engines.
You might run Google Ads to send people to them.
Then you waited for somebody to telephone, email or fill in a form.
Even ecommerce websites had relatively clear boundaries. Products went in, orders came out.
Modern websites can be much harder to define.
They can be publishing systems, databases, applications, shops, dashboards and automation platforms simultaneously.
Sometimes the public-facing pages are the least complicated part.
SEO Used to Influence the Structure Much Earlier
Building sites for SEO also encouraged a particular way of thinking about structure.
You thought about the searches you wanted.
Perhaps that was Suffolk SEO.
Perhaps it was SEO near me.
Perhaps it was web design in Felixstowe, ecommerce websites or Google Ads in Ipswich.
Then you created an information architecture that helped search engines connect the website with those subjects.
There is nothing inherently wrong with that.
Search intent still matters enormously.
But I am much less interested now in allowing a list of keywords to dictate what an entire website becomes.
I would rather build something genuinely useful first, then make sure search engines can understand the useful thing I've built.
I've Also Become Less Attached to Platforms
Developers can become strangely loyal to technology.
People identify as WordPress developers, Laravel developers, React developers or whatever else they happen to spend most of their day using.
I understand why.
Expertise is valuable.
But I've become much more interested in the outcome than the badge attached to the technology.
I still use WordPress.
I still write PHP.
I still use MySQL.
I also build standalone applications when that makes more sense.
Sometimes I deliberately remove a dependency rather than add one.
Sometimes the cleverest solution is unnecessary and the boring solution is perfect.
The question I care about is whether the technology makes the project easier or harder to evolve.
Owning the Project Changes Your Time Horizon
This is another major difference between client work and building something yourself.
A client project has milestones.
Design approved.
Development complete.
Content added.
Website launched.
Invoice paid.
There may be ongoing work afterwards, but there is normally a recognisable point at which the original project is finished.
My own projects don't really work like that.
They evolve.
I build something because I need it today.
Three months later I have enough data to realise it could do something else.
Six months later another project needs access to the same information.
A year later the thing that started as a tiny internal tool may have become an important part of how I work.
That makes flexibility much more valuable.
I've Learned to Be Suspicious of Convenient Decisions
One of the easiest mistakes in development is choosing something because you already know how to use it.
I've certainly done that.
There is comfort in beginning every project from the same familiar starting point.
But convenience at the beginning can become friction later.
You add a plugin because the platform doesn't quite do what you need.
Then another.
Then you override something.
Then you create a workaround for the override.
Eventually you've built an elaborate solution to a problem that only exists because of the decision you made on day one.
I am much more willing now to spend longer on that first decision.
Sometimes Removing Technology Is the Upgrade
We tend to talk about website development as a process of adding things.
New features.
New integrations.
New plugins.
New services.
New layers.
But some of the most satisfying changes I've made have involved removing something.
Taking a system I understand well and asking whether it still needs the framework it originally lived inside can be surprisingly liberating.
You discover which parts were genuinely useful and which parts existed because that was simply how the original platform worked.
The result can be smaller, faster and much easier to reason about.
That Doesn't Mean Everyone Should Build From Scratch
There is an important warning here.
Custom development is not automatically better.
If you need an ecommerce website and an established platform already solves 95 per cent of your requirements, rebuilding checkout, payment handling, stock management and order administration from nothing would probably be ridiculous.
If you need a straightforward company website, writing your own content management system simply because you can may be equally ridiculous.
I've built enough software to appreciate how expensive apparently simple features can become once you account for all the awkward edge cases.
The goal isn't custom development.
The goal is appropriate development.
My Old Web Design Work Still Shapes These Decisions
Although I don't really do traditional web-design work anymore, those years are still underneath almost everything I build.
Client work taught me that people don't care how clever the code is if they can't understand the interface.
SEO taught me that information needs structure.
Google Ads taught me that sending more people to a bad experience simply gives you a more expensive bad experience.
Ecommerce taught me that tiny pieces of friction can have measurable consequences.
Hosting taught me to think about reliability.
Support taught me that software eventually has to cope with somebody doing the one thing you never imagined they would do.
None of those lessons disappeared when I stopped actively selling those services.
They became ingredients in something else.
Today I Build From the Problem Outwards
If I have changed one fundamental thing about the way I approach a new project, it is this.
I try not to decide what the solution looks like too early.
I start with the irritating thing.
The missing information.
The repetitive task.
The opportunity I can't currently measure.
The two systems that ought to know about each other but don't.
The website that has accumulated useful information but isn't doing anything interesting with it.
Then I work out what needs building.
Sometimes the answer is WordPress.
Sometimes it is a standalone website.
Sometimes it is an API.
Sometimes it is a tiny script that runs automatically and nobody ever sees.
And occasionally the answer is that nothing needs building at all.
The Best Platform Is the One You Stop Thinking About
After more than 20 years of web development, I am probably less interested in technology for technology's sake than I have ever been.
I still love building things.
I still get excited when an idea starts working.
But the platform itself isn't the achievement.
The achievement is when the technology gets out of the way and the thing you wanted to create simply works.
For years, I started with the website and worked inwards.
These days, I start with the idea and work outwards.
It has made building much more interesting again.
