When I started building websites in the late 90s and early 2000s, the landscape was completely different. Back then, simply having an online presence was often seen as a significant step for a local business.
I spent a lot of time creating what were essentially digital brochures for shops, tradespeople and services around Felixstowe and wider Suffolk. They were relatively simple projects on the surface, but looking back, they taught me some of the most enduring lessons of my career.
The "Just Get Me Online" Era
For many local businesses, the internet was still a mysterious new frontier. Their main request was often simply to "get online". They wanted a few pages about the business, details of their services or products, and, crucially, a contact page with their phone number, address and perhaps a map.
The websites themselves were often static HTML, sometimes with a bit of Flash if somebody was feeling adventurous, and usually built largely from scratch.
What is interesting looking back is that some of those businesses didn't actually want more work.
They already had enough customers. They weren't asking me to generate leads, build sales funnels or find new markets. They simply felt that a proper business should have a website.
In those cases, the website really was about validating the existence of the business. If somebody heard the company name, saw one of their vans, received a recommendation or wanted to check their opening hours, there was somewhere online that confirmed who they were and how to contact them.
That might sound incredibly basic now, but at the time it served a genuine purpose.
It also taught me quite early that not every business problem is a growth problem. Sometimes the right solution is simply making an existing business easier to find, understand or trust.
Beyond the Brochure: What Actually Moved the Needle
As time went on and I built more of these sites, I started noticing patterns. A beautiful, perfectly coded website didn't necessarily produce a better business outcome.
Sometimes a very basic site with clear information and an obvious way to contact the business was considerably more useful than something visually impressive.
This was probably my first real lesson in the difference between building a technically good website and building a commercially effective one.
I started asking different questions.
What did the business actually need the website to do?
Did they want more phone calls? Did they want fewer phone calls asking the same basic questions? Did customers need to see a menu, opening hours, examples of previous work or a clearer explanation of the services they offered?
The answers were often much simpler than the technology.
These early experiences underlined something I later wrote about in What Building Websites for Local Businesses Taught Me About True Business Needs. The website itself was rarely the whole answer. It was simply a tool within the business.
The useful part was understanding the underlying problem and working out what the website could do about it.
The Unseen Value of Simplicity
There was a certain purity to those early projects. There weren't thousands of plugins, themes, integrations and services competing to become part of the solution.
If somebody needed a contact form, I might write the script that processed it. If they needed information displayed differently, I'd change the HTML. You ended up understanding exactly what every component was there to do because there weren't many layers between you and the finished result.
That way of thinking has stayed with me.
- Clarity beats complexity: people need to understand what something does and how to use it.
- Functionality comes before features: does it do what the user needs it to do, reliably?
- The website is a means, not an end: it exists to serve a wider purpose within the business.
As I touched upon in The Website Was Never Really the Finished Product, the interesting work often isn't the visible website at all. It's the systems, data and processes sitting behind it.
From Web Designer to Online Builder
Looking back, those simple local business websites were my training ground.
They taught me to listen to what somebody actually needed rather than automatically reaching for the most technically impressive solution.
That thinking has followed me into almost everything I've built since.
It's there when building systems that automate parts of a business. It's there when working with data. It's there in the AI-driven systems I'm building now, where different pieces of software need to understand information, make decisions and work together.
The technology is vastly more complicated than a five-page HTML website from the early 2000s, but the underlying question hasn't really changed:
What problem are we actually trying to solve?
Even managing Google Ads reinforced the same lesson from another direction. When you're paying for every click, you very quickly become interested in what people actually want rather than what you assume they want. I wrote more about that in What Paying for Every Click Taught Me About True Customer Intent.
Today I spend far more time building my own products, platforms and systems than building websites for clients, but I think those early projects still influence the way I approach all of them.
The tools have changed beyond recognition. The basic challenge hasn't.
Understand what somebody is trying to achieve, identify the real problem, and build the simplest effective solution.
Sometimes that solution might now involve APIs, databases, automation and AI.
And sometimes it might still just be a webpage containing a phone number and some opening hours.
The real lesson was never in the code. It was in understanding what makes a business tick.
If you're interested in how that eventually led me away from client work and towards building my own things, you might also enjoy Why I Stopped Building Websites for Clients and Started Building for Myself.
