Sales channel automation — eCommerce

They hired us for website maintenance.
We found the real bottleneck.

A luxury and rugged smartphone retailer, selling across their own site plus Amazon (8 regions), eBay, Newegg, and OnBuy, brought us in for basic nopCommerce upkeep. The actual problem — inventory, pricing, and orders scattered across five disconnected channels — turned into a platform their own client later sold as its own SaaS product.

Talk to an engineer Read the full story

Start
2 devs
Hired for website maintenance only
Diagnosis
5 channels
Inventory & pricing fragmented across every marketplace
Build
7 months
To first working version of the platform
Outcome
Own SaaS
Client later sold the platform as a product

The story

Scoped for a ticket,
sized for a platform

The client runs a strong direct-to-consumer web store on nopCommerce, plus storefronts across Amazon in eight regions, eBay, Newegg, and OnBuy. They came to us with a narrow ask: keep the website running smoothly under heavy traffic. We started with two developers doing exactly that.

As we got deeper into their operations, the actual constraint on their growth became clear: inventory, supplier pricing, and order management were manual and disconnected across every one of those five channels. They'd tried off-the-shelf tools like ChannelAdvisor and SellerCloud, but hit the usual wall — high cost, rigid workflows, and no real customization for how their business actually ran.

Rather than staying inside the original maintenance ticket, we proposed something bigger: a centralized management console with automated inventory sync, supplier price comparison, and competitor price tracking — purpose-built around their catalog and channel mix instead of forced into a generic tool.

We shipped the first working version in seven months, then kept iterating — server load distribution to fix a mid-project performance issue, deeper marketplace API integrations, and a custom price-calculation engine. Roughly 90% of the client's channel-management tasks are now automated, with our team still handling the manual exceptions. The engagement has run for close to three years.

Client: Luxury & rugged smartphone eCommerce brand
Sales channels unified: Own web store, Amazon (8 regions), eBay, Newegg, OnBuy
Core stack: nopCommerce, ASP.NET/C#, AWS (EC2, Lambda), Python price engine
Engagement length: ~3 years and ongoing, from 2-person maintenance to platform build
Notable outcome: Client repositioned the platform as their own SaaS offering

How it was built

Four phases, in the order they
actually happened

Building the management console
Integrated dashboards for every sales channel and supplier under one console, built on nopCommerce's plugin architecture with custom extensions and BI/analytics tooling layered on top.
Distributing server load
The first working version hit 100% memory utilization and database deadlocks under load, driving bounce rates up. We moved over a hundred scheduled processes to a dedicated daemon server to free the main server for scale.
Syncing supplier inventory
Connected Amazon's Selling Partner API, eBay's developer API, and the Newegg and OnBuy marketplace APIs on AWS (EC2 for hosting, Lambda for event-driven syncing) to keep inventory current across every channel automatically.
Automating price calculation
A Python-based pricing engine tracks competitor and supplier prices — including shipping, exchange rates, and delivery costs — and calculates the optimal listing price automatically across every channel.

increase in sales: 60%
reduction in bounce rate: 40%
lower operational overheads: 30%
of channel-management tasks automated: ~90%

How we scope work like this

Why this isn't a scope-creep story

We Won't
quietly expand a maintenance ticket into a platform build. We proposed the bigger system as a separate, explicitly-scoped decision — the client chose to fund it because the diagnosis was clear, not because it happened by default.
We Won't
tell every maintenance client their real problem is bigger than what they asked for. Most of the time, the ticket is the problem. This case is notable because it wasn't.
We Will
say so directly when we see a pattern across support tickets that points to a structural issue — and let the client decide whether it's worth fixing at that scale.