đź‘‹ A Quick Intro
I've been building and contributing for e-commerce platforms for the majority of my career for startups, multi-vendor marketplaces, and fast-growing businesses. During this time I made a lot of mistakes, made huge money loses I'm not proud of :D but most importantly I solved even more problems thus I learned what works and what doesn't.
This article is a simple summary of the key things I’ve learned. If you’re building an e-commerce system (whether for physical goods, digital goods, or services) I hope this helps you avoid the same mistakes and design better systems from the start.
đź’° 1. Just storing the final price is a long-term liability
Most platforms only store what the customer paid. It feels enough — until finance starts asking questions like:
- “What was our margin after fees and discounts?”
- “Why do two identical orders show different profitability?”
- “How much did this campaign really cost us?”
And that’s when you realize… you didn’t track any of it.
Why it matters:
If you only store the final paid amount, you lose visibility into how that price was built. And worse, if prices change over time, you have no way to go back and understand what the price was at the time of purchase. You’ll be blind to your own data — and reports will become guesswork.
What to do instead:
Break the price down into its components: base cost, discounts, shipping, tax, fees, etc.
And just as importantly — store historical pricing at the time of the order. Even if your pricing model evolves, the record of what was sold, at what cost and margin, should never change.
⚙️ 2. Not everything needs to go through a sprint
This one hits hard in growing teams.
Sometimes ops just needs:
- A way to export tracking numbers
- A quick CSV parser
- A hacky tool to clean vendor data or trigger a re-sync
But instead, we say:
“Let’s write a ticket → estimate it → groom it → prioritize it → plan it → build it.”
And while we plan, ops suffers.
Why it matters:
The difference between a 2-week feature and a 2-hour tool can be one hour of autonomy — and your willingness to move fast.
What to do instead:
When the solution is obvious and internal, build it. A dirty HTML file that exports shipment IDs can save days of manual work — and earn a lot of trust.
👉 Not everything needs a roadmap. Some things just need a quick win.
📦 3. Inventory is not a number — it’s a history
“10 in stock” looks fine — until someone asks:
- “Where did the stock come from?”
- “Was it sold or returned?”
- “Why are we off by 3 units?”
And there’s no way to answer.
Why it matters:
Ops teams rely on traceability. If you can’t explain changes, your stock levels are just guesses.
What to do instead:
Track every inventory movement — what changed, when, why, and who did it. You’ll prevent hours of manual tracing and avoid losing trust from internal teams.
🧾 4. If you can’t reconcile it, you can’t trust it
Everything looks good in the dashboard — until finance or vendors ask:
- “Why is Stripe reporting less than the platform?”
- “Why didn’t this vendor receive their full payout?”
- “Why is the total off by 3% this month?”
Why it matters:
If your numbers can’t be matched with bank or gateway records, no one will trust your reports — no matter how nice they look.
What to do instead:
Track the entire money flow — including gateway fees, commissions, VAT, and vendor shares. Your system should act like a financial ledger behind the scenes.
đźšš 5. Delivery logic must be swappable
You start with one delivery provider and build everything around them. Then ops says:
- “We’re switching to another courier.”
- “This one needs label printing.”
- “We need to support restaurant delivery.”
And now you’re rebuilding your delivery logic all over again.
Why it matters:
Tightly coupling your system to one provider makes you inflexible. Ops can’t move fast, and your dev team becomes a bottleneck.
What to do instead:
Design your delivery engine to support multiple providers. Think of each integration as pluggable — because they will change.
🧮 6. ERP integration will expose everything you skipped
At some point, someone will say:
“Can we sync orders and payouts into the accounting system?”
That’s when you realize:
- Discounts and fees are all lumped together
- There’s no mapping to account codes or payment types
- Tax is handled manually
- General Ledger integration is near impossible
Why it matters:
You can’t close the books — or scale operations — without clean financial data.
What to do instead:
Even before ERP is in scope, structure your financial records to reflect reality: revenue, cost, tax, fees, commissions, etc.
đź•“ 7. Status history is more valuable than current status
Everyone looks at the current order status. But when problems happen, people ask:
- “When did it move to paid?”
- “How long was it stuck in shipped?”
- “Who changed it manually?”
And you realize: you don’t know.
Why it matters:
A single status field tells you nothing about the journey. And that’s where the root causes live.
What to do instead:
Track every status change — timestamp, user, and reason. This is how you trace issues, measure SLAs, and answer vendor questions with confidence.
👀 8. No audit logs? You’ll regret it
In small teams, you can ask around:
“Did someone edit this?”
“Who updated the payout?”
But in a growing company, across shifts and regions — that’s impossible.
Why it matters:
Without audit logs, everything becomes a guessing game. And that slows teams down.
What to do instead:
Log every change to sensitive data: orders, inventory, prices, vendors. This isn’t about control — it’s about trust, transparency, and traceability.
đź“Š 9. Reporting is not analytics
Early on, it feels enough to just show raw data in dashboards: sales totals, order counts, top products. But soon, stakeholders start asking:
- “Which marketing channel drove the highest-margin sales?”
- “Which customers are profitable vs. loss-making?”
- “What’s the true CAC vs. LTV?”
And your system can’t answer.
Why it matters:
Dashboards with raw numbers don’t drive decisions. Without context and proper breakdowns, data becomes noise — not insight.
What to do instead:
Design reporting with analytics in mind:
- Tag data by source (campaign, channel, customer segment)
- Track cohorts and profitability, not just revenue
- Build the ability to drill down, not just sum up
Good analytics will drive better product decisions, marketing spend, and operational efficiency.
âś… Final thoughts
Most e-commerce systems don’t collapse because of a bug in the code. They collapse when teams are forced to scale on top of fragile foundations.
In my experience, the systems that thrive over time are the ones that are easy to explain to others, trusted across departments, and resilient to change. You can trace every order. You can justify every payout. You can onboard new team members without a wall of confusion.
These platforms aren’t just “built” — they’re designed with care, with structure, and with a clear understanding of what’s coming next.
If you’re in the middle of building, scaling, or even cleaning up an e-commerce platform, I hope these lessons help you think a few steps ahead.
And if you’ve been through some of this already — I’d love to hear what you learned along the way.
Top comments (0)