Brands Define Ecommerce Data Models
Sara Du, co-founder and CEO of Alloy, on building the Switzerland of ecommerce software
This is why middleware becomes the natural control layer in ecommerce. Each app treats a customer or order as a slightly different thing, because each app was built for a narrow job. A reviews tool cares about review history and product affinity. A storefront cares about checkout, payment, and fulfillment. Alloy sits between them so a brand can decide which fields matter, map them once, and run workflows across the whole stack without forcing everything into one app’s schema.
-
The practical problem is not just moving data, it is translating meaning. In commerce, orders, line items, fulfillments, and delivery data are modeled differently across platforms, and those differences change with industry needs. A fixed universal schema usually covers the common 20% to 30%, then misses merchant specific fields and logic.
-
That is why Alloy emphasizes long, multi-step workflows instead of simple syncs. A brand might read an order from Shopify, check subscription rules in ReCharge, branch on fulfillment conditions, add a gift, apply a discount, update support tools like Gorgias, and send marketing data downstream. That only works if the system exposes deep field coverage and flexible mapping.
-
The closest comparison is Rutter, but the split is important. Rutter gives software companies a common API for commerce data. Alloy gives merchants and product teams a workflow layer to configure how apps behave together. One abstracts APIs for developers. The other becomes the operating logic for the merchant stack.
As ecommerce stacks keep fragmenting into specialized apps, the winning integration layer will not be the one with the most connectors, it will be the one that lets brands define their own data model and business logic. That pushes Alloy beyond automation and toward becoming the system where commerce data is shaped, not just passed around.