One back office, several stores.

A single database stores your products, your stocks and your orders. On the front end, each store is a configured instance: its domain, its design, its display rules and its commercial rules. The customer only sees their store, you only manage a single back office. A single data source, several storefronts: nothing to synchronize, nothing to re-enter.

Yes, it's one of the main use cases. Each store applies its rate grid: public prices, volume prices, negotiated discounts, tiered rates. Promotions can also be specific. Everything is centralized in the back office, you don't have to maintain two price lists in parallel.

Yes. The B2B store can accept only bank transfer or 30-day invoicing, the B2C store can accept credit card, PayPal or Apple Pay. Delivery methods follow the same logic. Each store defines its options, the back office manages everything from a single place.

No. It's the central principle of the architecture: the database and the back office are shared, each store is a front-end configuration. Opening a new store means creating an instance: domain, theme, specific content, commercial rules. Count weeks of configuration, not months of development.

We define a clear scope with you: what is global (product pages, images, descriptions) and what is specific to each store (rates, specific texts, information pages). Global content is updated once and displays everywhere. Specific content only appears in its store. You decide the boundary, the architecture doesn't impose it.

The budget depends on the complexity: number of stores, level of customization of each front end, specific commercial rules. The infrastructure (unified back office, database) is mutualized: it's built once and serves all your stores. You receive a detailed costing after a scoping exchange, with no commitment.

Yes. We start from your existing store, we identify what already exists in your PIM, your ERP or your current back office, then we build the multi-store architecture around what exists. The migration is progressive: we set up the new architecture, we migrate the data, then we switch the traffic. Your e-commerce keeps running during the transition.