Company tech stack

An ecommerce company's tech stack is the set of systems that together run the business: the storefront, the systems that manage orders and inventory, the warehouse and carrier layers that move goods, the returns platform, and the support tooling that handles customers. What makes it a stack rather than a list is the integrations between the layers, which is where most operational behavior, and most operational failure, actually lives. How to choose between the options at each layer is best tech stack for ecommerce.

Decide which system holds the order status everything else reads

The ERP holds financial, inventory, and often purchasing records and acts as the system of record for the business. The OMS orchestrates orders across channels and locations and decides where each is fulfilled. Businesses run one, the other, or both, and where both are present the boundary between them needs deliberate definition, since overlapping responsibility for inventory or order state is a common source of divergence. For post-purchase purposes the relevant question is which of them holds the authoritative order status that customer-facing systems should read. The layer in question is the order management system, the application view of it is ecommerce application, and the vocabulary for the terms is settled in the CSCMP supply chain glossary.

The warehouse knows whether the order was picked, and the storefront does not

The warehouse management system runs the physical operation: receiving, putaway, picking, packing, and dispatch. It is the layer that knows whether an order has actually been picked, which is information the storefront does not have. Inventory visibility is the joint output of the WMS and whatever holds stock records, and its accuracy determines oversell risk. Businesses using third-party logistics providers substitute the provider's system, which usually means less granular visibility and a dependency on their integration quality and update frequency. Whether two systems are even describing the same physical event the same way is what the GS1 EPCIS standard exists to settle, and the failure it prevents shows up as split shipments and oversells.

Tahir Rauf, my co-founder and our CTO, calls this the spaghetti stack, and the phrase has stuck with me because it describes the shape of the problem better than any architecture diagram. Disconnected ERPs, warehouse systems, carriers and returns platforms, each one solid on its own, none of them able to answer a question that crosses two of them. Nobody built that on purpose. It accumulated, and the layer that connects them is the piece nobody was ever asked to buy. Running one stock pool across several channels on top of it is multichannel retailing.

The layer with the most events and the least control

The carrier layer covers rate selection, label generation, manifesting, and tracking events. Most businesses run multiple carriers, either directly or through an aggregator. This layer produces the events that drive customer-facing tracking, so its event coverage and latency determine how current the post-purchase experience can be. It is also the layer with the least control, since the carrier's performance and reporting are outside the business's operation, which is why carrier integration is its own discipline and why carriers publish their own standards to be measured against, as USPS does. The tooling category built on it is parcel software.

Returns handled by email show up as refund latency

The returns platform handles request intake, policy enforcement, label issue, inbound tracking, and the refund or exchange decision. Its integrations run in two directions: to the storefront and payment provider for refunds, and to the warehouse for receipt and inspection. Where returns are handled outside a dedicated platform, typically by email and manual processing, the characteristic symptoms are inconsistent decisions and refund latency, both of which generate support contact. The category is returns management software, the process is returns management, and the outer bound on the refund is 16 CFR Part 435.

Support is where upstream stack failures become visible

The helpdesk holds contacts and their history. Its value in an ecommerce stack depends heavily on its integrations to the order and fulfillment layers, since an agent without order context is working from the customer's account of events. The system is the helpdesk. Deflection tooling sits alongside it, answering order-status and returns questions before they become contacts, which is customer self-service. This layer is where the cost of upstream stack problems becomes visible and measurable, which is why contact reason mix is a useful diagnostic for the whole stack rather than for support alone. The measures are on ecommerce KPIs and the discipline that reads them is customer complaint management.

Here is the failure that actually costs money and it is not dramatic. The schedulers between the storefront, the ERP and the warehouse system fail quietly, and the only signal anybody gets is a customer ticket. Not an alert, not a red light on a dashboard, a customer. Every order is a promise, and a stack that reports its own failures through the support inbox has made the customer the monitoring system. That is the single most useful thing to check about any stack: not what it connects, but how you find out when a connection stops. It is the same argument I have made about carriers on Add To Cart, and the operating model that answers it is post-purchase operations.

That is not a rare configuration. When we categorized the 786 pain points we mined from 270 customer call transcripts between May 2025 and May 2026, system sync failures were the largest single category, with 94 separate mentions across prospects and deployed customers, and the schedulers and webhooks between the storefront, the ERP and the warehouse system were the usual culprits: failing quietly, failing intermittently, and reported by nobody until a customer wrote in.

A notification is only as true as the event that fired it

The notification layer sends order and delivery messages, triggered by events from the layers above. Its accuracy is entirely inherited: a notification saying an order shipped is only true if the event that triggered it was true. The architectural question is which system owns the trigger and whether it evaluates expected events as well as received ones, because the most valuable message, the delay notice, is triggered by an event that did not happen. The message set is shipping notifications and the flow layer is ecommerce email marketing automation.

• Council of Supply Chain Management Professionals. CSCMP supply chain glossary. Settled definitions for ERP, OMS and their boundary.
• GS1. GS1 EPCIS standard. Two systems describing the same physical event the same way.
• United States Postal Service. USPS does. The carrier layer publishing its own standard to be measured against.
• US Electronic Code of Federal Regulations. 16 CFR Part 435. The refund latency the returns layer is bounded by.