We Didn't Need More Traffic.
We Needed a Better System.
What 18 years in technology taught me about turning an e-commerce operation from roughly £150,000 a year to £3.5 million — and why growth is rarely just a marketing problem.
The business didn't have a traffic problem.
It had a systems problem.
When I first got involved, the business was doing roughly £150,000 a year. Three years later, it was doing around £3.5 million.
That's roughly 23× revenue growth.
The obvious story is that we found a way to sell more shelves.
That's not really what happened.
The interesting part wasn't the website. It wasn't Google Ads. It wasn't Amazon.
It was what happened when all of those things started becoming one system.
1. The website wasn't really the business
It's easy to look at an e-commerce company and think the website is the product.
It isn't.
The website is one interface into a much larger machine.
Once an operation starts getting busy, a change in one part of that diagram can have consequences everywhere else.
Add a product and you may need images, descriptions, pricing, attributes, feeds and advertising data. Change stock and several sales channels may need to know. Change an order and fulfilment, customer service and inventory can all become involved.
That's why I stopped thinking about the website as a website.
I started thinking about it as the front end of an operating system for the business.
2. Every new sales channel multiplied the complexity
Adding another marketplace sounds simple.
“Let's sell on Amazon.”
Then B&Q. Then eBay. Then Etsy. Then another channel.
But every channel brings its own catalogue rules, APIs, order formats, stock behaviour, fulfilment requirements, fees and failure modes.
At small scale, people can patch those differences manually.
At larger scale, manual processes become a tax on growth.
Growth creates complexity. Good systems absorb the complexity so people don't have to.
That became one of the recurring themes of the work: don't just connect two systems. Build a reliable layer between them.
Products needed to move. Orders needed to move. Stock needed to move. Errors needed somewhere to go. Retries needed to happen. And, importantly, someone needed to be able to see when something hadn't worked.
That is where APIs, automation and integration architecture stopped being “technical work” and became commercial infrastructure.
3. Marketing and technology became inseparable
I've worked across Google Ads, Microsoft Ads, Amazon Ads, Google Merchant Centre, SEO and e-commerce analytics.
But the more I worked with those systems, the less sense it made to treat marketing as something separate from technology.
A paid search campaign is only as good as the products behind it. A product feed is only as useful as the catalogue data. A landing page only matters if it converts. A conversion only matters if the economics work.
So the real chain looked more like:
Once you see it that way, “improve the ads” is a surprisingly incomplete instruction.
Sometimes the problem isn't the advert.
Sometimes the product data is wrong. Sometimes the stock isn't available. Sometimes the landing page is poor. Sometimes the tracking is broken. Sometimes the margin doesn't support the acquisition cost.
Technology sits in the middle of all of it.
4. Growth exposes technical debt
A system that handles twenty orders a day can survive things that become catastrophic at a thousand.
A manual export becomes an afternoon of work. A slow query becomes an operational bottleneck. A brittle integration becomes a missed order. A small data inconsistency becomes hundreds of incorrect listings.
This is one of the reasons I like working close to real businesses.
You quickly discover which technical problems actually matter.
Not every piece of technical debt deserves a rewrite. Not every old system needs replacing. Sometimes the right answer is an elegant new architecture. Sometimes it is a small script that removes an hour of repetitive work every morning.
The best technical decision is rarely the most technically impressive one. It's the one that changes the outcome.
That mindset is probably the biggest change in my own career.
Earlier on, I was interested in how things were built.
Now I'm much more interested in what becomes possible because they were built.
5. The real product was the system
At one point the operation could handle roughly 1,000 orders a day across a large catalogue and multiple channels.
That doesn't happen because somebody writes a particularly clever piece of code.
It happens because hundreds of small decisions line up:
How is product data structured? How does stock move? How do orders enter the system? What happens when an API fails? How are ads measured? How are products mapped between platforms? What gets automated? What still needs a human? Where does the data live? Who gets alerted when something breaks?
Those questions are architecture questions.
They're also business questions.
And that is the bit of technology I find most interesting.
So what actually caused the growth?
There wasn't one magic lever.
We improved the website. We improved acquisition. We added sales channels. We improved product presentation. We built integrations. We automated repetitive processes. We made the infrastructure more capable. We connected systems that previously behaved like isolated islands.
Most importantly, we kept doing those things as one connected programme rather than treating them as unrelated projects.
That distinction matters.
You can have a great website and terrible operations. You can have excellent advertising and poor stock management. You can have modern software sitting on top of broken processes.
Technology only creates leverage when the pieces work together.
The lesson I took away
I've spent roughly 18 years working across software, e-commerce, infrastructure, digital marketing, integrations and business systems.
The older I get, the less interested I am in technology for its own sake.
I'm much more interested in the gap between:
“This is what the business wants to achieve.”
and
“This is what the technology currently allows it to do.”
That's the interesting bit.
It's where software meets operations. Where product meets engineering. Where marketing meets data. Where strategy eventually has to become something that actually works on a Tuesday morning.
And it's why I'm increasingly interested in the roles that sit between those worlds.
Technical product. Digital transformation. E-commerce leadership. Business systems. Technology strategy. The jobs where you need to understand the technology deeply enough to challenge it, but the business well enough to know what is worth building.
I've spent a long time learning how to build the machine.
Now I'm more interested in deciding which machine should exist in the first place.