The E-commerce Tax.
Why every new channel, feature and integration makes your business harder to run.
Your biggest e-commerce problem probably isn't conversion rate. It's the 47 things happening behind the checkout that nobody wants to talk about.
There is a peculiar thing that happens when an e-commerce business starts growing quickly.
Everyone celebrates the obvious numbers.
Revenue is up.
Orders are up.
Customers are up.
New markets are opening.
Another marketplace has launched.
Another warehouse is coming online.
Another product range is being added.
From the outside, it looks like progress.
And it is.
But there is another number that almost nobody puts on the dashboard.
Complexity.
Because every successful decision creates another system to maintain.
Every new channel creates another set of rules.
Every integration creates another dependency.
Every feature creates another thing that can break.
Every exception creates another manual process.
Eventually, the business can become very good at generating revenue and surprisingly bad at operating itself.
Growth creates complexity. Complexity creates cost. Eventually, complexity becomes the thing stopping you from growing.
1. Growth is supposed to make things easier
When an e-commerce business is small, you can get away with an astonishing amount of chaos.
Someone notices an order is wrong and fixes it.
Someone updates a spreadsheet.
Someone emails the warehouse.
Someone knows which customer needs a refund.
Someone remembers that one marketplace works differently.
And because everyone is close to the operation, the gaps between systems are mostly invisible.
Then the business grows.
100 orders become 500.
500 become 1,000.
One sales channel becomes five.
One country becomes several.
A handful of products becomes thousands of SKUs.
The old informal processes don't disappear.
They multiply.
Suddenly someone isn't fixing one order.
They're fixing the same class of problem 40 times a day.
That is when a process stops being an inconvenience and becomes an architecture problem.
2. Every new thing creates a tax
Let's take the decisions that normally look like obvious growth opportunities.
Add Amazon.
Now you have another catalogue, another order flow, another pricing environment, another returns process and another set of marketplace rules.
Add another marketplace.
Another integration.
Another attribute mapping.
Another failure mode.
Sell internationally.
Now think about currencies, taxes, delivery, localisation, returns and regulatory requirements.
Add a new warehouse.
Now stock isn't simply stock. It has a location.
Add a promotion.
Now pricing has conditions.
Add a new payment provider.
Now reconciliation has another moving part.
Add AI.
Now you have another layer of automation, permissions, governance, monitoring and risk.
None of these decisions is necessarily wrong.
That's the problem.
Complexity rarely arrives because somebody made one terrible decision.
It arrives because hundreds of perfectly reasonable decisions accumulate.
3. The 1% problem
Large e-commerce operations are often not destroyed by one giant failure.
They're worn down by tiny failure rates.
1% of orders have a problem.
1% of products have incorrect data.
1% of stock movements don't reconcile.
1% of marketplace updates fail.
1% of customers need manual intervention.
1% sounds harmless.
Until you have 100,000 orders.
Then 1% is 1,000 problems.
And if each problem takes ten minutes to investigate, you're looking at roughly 167 hours of human work.
That's more than four full working weeks.
For one percentage point.
This is why scale changes the economics of bad systems.
At small scale, inefficiency is annoying. At large scale, inefficiency becomes a line item.
4. Your architecture becomes your organisation
This is one of the most interesting effects of fragmented e-commerce systems.
The technology architecture starts shaping the organisation.
Marketing has one source of truth.
Finance has another.
Operations has another.
Customer service has another.
The warehouse has another.
Everyone builds workarounds around the gaps.
Eventually, people are spending their time managing the interfaces between departments rather than improving the customer experience.
You get meetings about data.
Meetings about whose number is correct.
Meetings about why an order didn't sync.
Meetings about why stock is different in three systems.
Meetings about the meeting that was supposed to fix it.
At that point, the architecture is no longer just a technical concern.
It is the shape of the organisation.
5. The spreadsheet isn't the enemy
I actually like spreadsheets.
They're incredibly useful.
They are fast, flexible and brilliant for experimentation.
The problem is what happens when a spreadsheet becomes infrastructure.
Someone exports orders every morning.
Someone cleans the file.
Someone adds a column.
Someone copies a formula.
Someone emails it to someone else.
Someone uploads it into another system.
And everybody knows that if the spreadsheet stops working, the operation stops working.
The spreadsheet isn't necessarily the problem.
It's evidence that the underlying system hasn't caught up with the business.
6. The integration graveyard
Every established e-commerce business has some version of this.
The plugin nobody wants to update.
The API integration written years ago by someone who has left.
The scheduled job everyone assumes is still running.
The mystery database table with a name nobody recognises.
The field called custom_field_17.
The process that works perfectly provided nobody changes anything.
The server that absolutely must not be rebooted.
The integration that technically works but nobody understands.
And, inevitably, the person who knows how the whole thing works.
That's a single point of failure wearing a staff badge.
This is one of the most dangerous forms of technical debt because it doesn't necessarily appear on a balance sheet.
It appears as fear.
“Don't touch that.”
“We've always done it this way.”
“Nobody knows what will happen if we change it.”
Those are architecture warnings disguised as operational advice.
7. Technical debt isn't really technical
Technical debt is often discussed as though it belongs to developers.
It doesn't.
Eventually technical debt becomes:
If launching a new country takes six months because nobody understands the integrations, that's a commercial problem.
If a marketing experiment requires three teams and a spreadsheet, that's a commercial problem.
If adding a marketplace takes months because the catalogue architecture can't support it, that's a commercial problem.
If a fulfilment failure requires five people to diagnose manually, that's a commercial problem.
The code is merely where the problem happens to live.
8. The scale paradox
There is a strange paradox in e-commerce.
The bigger the business becomes, the more it needs to simplify.
A small company can survive on tribal knowledge.
A large company cannot.
At £10k a month, somebody can manually fix an order.
At £100k, it's annoying.
At £1m, it becomes a process.
At £10m, it becomes an architecture problem.
The mistake is assuming that growth means adding more people to handle the complexity.
Sometimes it does.
But if every increase in volume requires a proportional increase in manual effort, you've built a business with linear complexity.
The goal should be different.
Revenue should grow faster than operational complexity.
9. Build for the next order of magnitude
One of my favourite questions when evaluating a system is simple:
“What happens if this is ten times bigger?”
Ten times the orders.
Ten times the products.
Ten times the customers.
Ten times the marketplaces.
Ten times the data.
Ten times the exceptions.
A solution that works today may collapse completely under that question.
And that's useful information.
You don't necessarily need to build for ten times today's scale immediately.
But you should know what breaks first.
Sometimes the answer is the database.
Sometimes it's an API limit.
Sometimes it's a human approval.
Sometimes it's a spreadsheet.
Sometimes it's a person.
And sometimes the biggest bottleneck isn't technical at all.
It's a business rule nobody has ever written down.
10. The hidden cost of exceptions
Most systems are designed around the happy path.
Order comes in.
Payment succeeds.
Stock exists.
Warehouse fulfils it.
Courier delivers it.
Customer is happy.
Real businesses don't work like that.
Payment fails.
Stock is wrong.
A product is discontinued.
A marketplace changes its API.
A courier loses something.
A customer changes their address.
A promotion overlaps another promotion.
An order is partially fulfilled.
A supplier misses a delivery.
The important architecture isn't just the happy path.
It's what happens when reality happens.
Good systems don't eliminate exceptions. They make exceptions cheap to handle.
11. Observability becomes a commercial capability
When systems become complicated, knowing that something has broken isn't enough.
You need to know:
What broke?
When did it break?
How many customers are affected?
How much revenue is at risk?
Which products are affected?
Which channel?
What caused it?
Has it happened before?
Did the system recover?
Can it safely retry?
Should somebody intervene?
This is why monitoring and observability aren't merely engineering conveniences.
They're increasingly commercial infrastructure.
A business that can detect and recover from problems quickly can operate differently from one that discovers them through an angry customer email.
12. The danger of adding another tool
There is a temptation in modern e-commerce to solve every problem by buying another platform.
Need better reviews?
Buy a tool.
Need personalisation?
Buy a tool.
Need analytics?
Buy a tool.
Need automation?
Buy a tool.
Need AI?
Buy a tool.
Sometimes that's exactly right.
But every new system has a cost beyond the subscription.
Data has to move.
People have to learn it.
Permissions have to be managed.
Failures have to be monitored.
Contracts have to be maintained.
Integrations have to be supported.
Eventually someone has to remove it.
The real cost of software is rarely the licence fee.
The cheapest system is often the one you don't have to integrate.
13. Sometimes the best feature is deletion
Technology teams are naturally biased toward building.
New feature.
New dashboard.
New integration.
New automation.
New workflow.
But mature e-commerce businesses often get more value from removing things.
Remove a manual approval.
Remove duplicated data.
Remove a redundant integration.
Remove an unnecessary report.
Remove a legacy workflow.
Remove a product feed nobody uses.
Remove a rule that exists only because of a historical problem.
Delete the thing that requires another thing to exist.
That's often where the biggest simplification happens.
14. The human bottleneck
There is another form of complexity that technology people sometimes overlook.
Decision-making.
Imagine an order flowing through ten systems perfectly.
Then it hits a human approval queue.
Someone checks it.
Someone else approves it.
Someone emails another team.
Three hours later, the order continues.
The architecture might be technically excellent.
The process is still slow.
This is why digital transformation can't simply mean replacing old software with new software.
You have to examine the decision itself.
Why does a human need to approve this?
What information are they checking?
Could the rule be expressed?
What happens if the confidence is low?
Could the system handle the normal cases and escalate only the exceptions?
This is where automation and AI become genuinely interesting.
15. The future isn't complexity-free
I don't think the answer is to stop adding channels, products, countries or capabilities.
That would be the wrong lesson.
Complexity is often the price of opportunity.
The objective is to make complexity manageable.
Good architecture doesn't mean having fewer systems.
It means having clear boundaries between them.
Good data doesn't mean everything lives in one database.
It means everyone understands what the data means.
Good automation doesn't mean removing humans.
It means humans spend their time where judgement actually matters.
Good e-commerce operations don't mean nothing ever goes wrong.
They mean problems are visible, contained and recoverable.
16. What I would measure instead
Revenue still matters.
Conversion still matters.
Average order value matters.
Customer acquisition cost matters.
Margin matters.
But I would increasingly want to see another set of numbers.
Because these numbers tell you something about the ability of the business to scale.
A company with slightly lower conversion but dramatically lower operational complexity may be in a much stronger position.
A company that can launch a new market in weeks rather than months has an advantage that doesn't necessarily appear in today's revenue report.
A company that can process ten times as many orders without ten times as many people has built leverage.
17. The e-commerce flywheel should get easier, not harder
The ideal mature e-commerce operation should look something like this:
Growth creates more information.
Information creates better decisions.
Better decisions improve the system.
The improved system reduces the cost of growth.
That is the flywheel.
The opposite is also possible.
More customers create more manual work.
More manual work creates more errors.
More errors create more exceptions.
More exceptions create more staff.
More staff create more coordination.
More coordination creates slower decisions.
And suddenly growth is making the business worse.
18. Make the next million easier than the last
This is probably the simplest way I think about e-commerce architecture.
Don't just build a system that can handle today's revenue.
Build a business that becomes easier to operate as it grows.
If you add a marketplace, the next marketplace should be easier.
If you add a country, the next country should be easier.
If you add a product range, the next range should be easier.
If you add an AI capability, the next one should be easier.
If you double order volume, the operation shouldn't feel like it doubled in difficulty.
That's what good systems architecture ultimately provides.
Leverage.
The uncomfortable bit
There is a point in almost every growing e-commerce business where someone has to admit that the thing that got them here won't necessarily get them there.
The plugin stack that worked at £20k a month.
The spreadsheet that worked at 100 orders a week.
The manual process that worked when everyone sat in the same room.
The integration written as a quick fix.
The database structure nobody wants to revisit.
The person who knows everything.
They may all have been perfectly rational choices at the time.
That's not a reason to keep them forever.
Good technology leadership isn't about criticising the past.
It's about recognising when the economics have changed.
The question isn't whether the system works.
The question is whether the system still makes sense at the scale you're trying to reach.
So what should a Head of E-commerce actually worry about?
Not just conversion.
Not just traffic.
Not just revenue.
Not just the next marketplace.
I'd worry about the system underneath all of those numbers.
Can the business absorb another order without creating another piece of manual work?
Can it launch a new channel without creating a new operational nightmare?
Can people trust the data?
Can the organisation see when something breaks?
Can it recover quickly?
Can new employees understand the systems without finding the one person who knows everything?
Can the business experiment without being frightened of its own architecture?
Can it use AI safely because the underlying data and processes are good enough?
And perhaps most importantly:
Can the next million pounds of revenue be easier to operate than the last million?
That's the real test.
Because the goal of technology in e-commerce isn't to create an impressive collection of systems.
It is to create leverage.
More revenue.
More customers.
More products.
More channels.
More intelligence.
Without multiplying the amount of chaos required to run the business.
Growth is exciting.
Scale is impressive.
But leverage is the point.