Commerce behaves differently in every sector.

Builders merchants and trade, foodservice and beverage, manufacturing and industrial, automotive and parts, retail and home, and health and wellness. These are the operations where the patterns repeat: ERP-integrated pricing, branch or depot stock, trade accounts and deep catalogues.

Yes, on the right brief. Sector pages exist where the operational pattern repeats often enough to compound experience. Outside those sectors, iWeb still takes work where the trading model fits: ERP-integrated commerce, complex catalogue, B2B trade or multi-territory operation.

Because most ecommerce friction is operational, not cosmetic. Pricing rules, stock logic, account structures, fulfilment routes and ERP boundaries differ by sector. Knowing where the patterns repeat means projects start with the right shape rather than learning it during build.

Trade-account commerce with customer-specific pricing, branch stock visibility, click and collect, ERP-integrated credit terms and depot-aware delivery. Usually on Adobe Commerce or Magento with PIM-governed trade catalogues and a written integration boundary with the merchant ERP.

B2B wholesale and foodservice ordering with depot-aware cut-offs, route-based delivery windows, account-specific catalogues and ERP-integrated pricing. The catalogue often blends ambient, chilled and frozen, with substitution logic and order-pad workflows tuned to how customers actually reorder.

ERP-integrated B2B commerce with PIM-governed technical catalogues, variants by specification, account quote-to-cart and integrations into Microsoft Dynamics, SAP, Epicor or proprietary ERPs. The pattern fits engineered products, industrial distributors and direct-to-trade manufacturers.

Parts and fitment-led commerce with PIM-governed technical attributes, vehicle compatibility logic, regional catalogue variants and integrations into parts ERPs. Direct experience on Adobe Commerce and Magento where the catalogue depth and B2B model already fit the platform.

Multi-territory retail with PIM-led product experience, lifestyle merchandising and search tuned to a retail query mix. Direct project experience on Adobe Commerce and Magento; the pattern applies to other platforms where merchandising and catalogue tooling support it.

Supplements, vitamins and wellness commerce with subscription, regulated-content rules, practitioner workflows and account management. Direct project experience on Adobe Commerce and Magento; the pattern applies to other platforms where subscription and account tooling support it.

They are inputs to the platform decision, not implementation details. ERP shapes pricing and stock; PIM shapes catalogue and attribute governance; stock shapes order routing and fulfilment promise. The platform is chosen against those inputs rather than the other way round.

Account-aware storefronts with shared catalogue and divergent pricing, account-only ranges, credit terms and trade-only features behind login. The same storefront can serve both audiences honestly when the catalogue and account structure are modelled for it from the start.

Account hierarchy, contracted pricing, credit limits, payment terms, approvers and account-only catalogues mirrored from the ERP. The storefront reads the account view live where it matters and caches where it can; reconciliation back to the ERP is monitored, not assumed.

Stock and fulfilment promise are computed against branches or depots, not a single national pool. Click and collect, partial dispatch and branch transfer are modelled in the OMS where the operation needs them, with the boundary to ERP and WMS written down.

Pallet, hazardous, chilled, oversized, kit-build and installation are catalogued where the sector needs them. Carrier selection, surcharge logic and route-aware promises are wired into the OMS rather than left to the storefront to guess at checkout.

Trade catalogues need technical attributes and supplier data; foodservice needs allergens and pack data; automotive needs fitment data; health needs regulated content. PIM is shaped to each pattern rather than forced into a generic template. The attribute model is named, not inherited.

Trade and complex B2B usually favour platforms with deep account, pricing and catalogue modelling. Lighter retail can land cleanly on simpler platforms. iWeb names the trade-off in writing rather than defaulting to a preferred vendor for every sector.

Case studies are labelled by sector and operational shape, not by logo. Adjacent projects are labelled adjacent. Outcomes are evidenced and the right to publish is held. There are no anonymous logos or unverifiable claims in the proof set.

Because the work behind the storefront differs: pricing rules, account structures, stock logic, fulfilment routes, ERP boundaries and regulatory content all change. Two clean-looking storefronts in different sectors are doing very different things behind the scenes.

Trade account pricing drift, stock accuracy across branches, regulatory content, allergen and hazard data, fitment errors and territory tax differ in weight by sector. iWeb names the main operational risks early so trading and integration design address them by build, not at launch.

Trade and foodservice trade through the working day with little tolerance for outages; multi-territory retail trades across time zones; health and regulated catalogues need editorial review on every release. Support cadence and on-call cover are shaped to the trading window rather than offered as one template.

When the operational shape is starting to outgrow the storefront, when the ERP or PIM boundary is becoming the bottleneck, or when a sector-specific buyer behaviour change is not being served. A senior written read can be commissioned ahead of any commitment to a build or replatform.