Platforms iWeb delivers
Every commerce platform we work on, with a page for each. If your platform decision is still open, start with platform-agnostic.
How this platform fits the wider commerce estate.
Questions we get asked.
How does iWeb choose between ecommerce platforms?
Against operational shape: catalogue depth, trade complexity, ERP integration, multi-territory rules and five-year cost. The decision is written down with trade-offs and is sized to the brief rather than to a vendor demo. Where the existing platform is the right answer, iWeb will say so on the record.
When does Adobe Commerce make sense?
Where deep B2B trade, complex catalogue, account-specific pricing and ERP integration are central to the operation. Adobe Commerce models these patterns natively and iWebs deepest pattern of engineered builds sits there. The trade-off is licence cost and engineering weight, which is named upfront.
When does Magento Open Source still make sense?
For merchants who have a working Magento 2 estate and where the operating model does not yet justify moving to Adobe Commerce. iWeb supports, extends and stabilises Magento Open Source where the brief fits, with an honest read on when a move to Adobe Commerce starts to pay back.
When does Shopify Plus make sense?
Where the operational shape fits inside Shopify Plus without bending it: lighter B2B, clean catalogue, sensible territory model and an integration boundary that the connector set can serve. iWeb will say so if the model is too complex for Shopify Plus rather than force it.
When does BigCommerce make sense?
Where the merchant has chosen BigCommerce and wants a senior engineering team behind it, or where a clean B2B and B2C blend, multi-storefront pattern and decent ERP connector path fit the operation. iWeb assesses fit against the brief rather than positioning BigCommerce as a default.
When does commercetools make sense?
Where composable genuinely earns its place: catalogue services, pricing services, search and storefront all needing independent release cycles and team ownership. The trade-off is integration surface area, which iWeb names early so the operating model is sized for what composable actually demands.
When does Hyvä Commerce make sense?
Where storefront performance is the bottleneck on an Adobe Commerce or Magento estate and a full replatform is not justified. Hyvä is a storefront layer; the trade-off is the migration cost from the existing storefront, which iWeb sizes against the trading benefit before committing.
What does platform-agnostic commerce mean here?
The platform decision is genuinely open and the brief is to choose against the operation, not to be sold a platform. iWeb gives a senior written read on Adobe Commerce, Magento, Shopify Plus, BigCommerce, composable and the rest, against the actual catalogue, trade, ERP and territory model.
How is B2B ecommerce handled across platforms?
Account hierarchy, customer-specific pricing, contracted credit, approver workflows, account-only ranges and quote-to-cart are designed against how the ERP models the customer. Where a platform models B2B natively, the work is configuration; where it does not, the trade-off is named in writing rather than hidden.
How is B2C ecommerce handled across platforms?
Catalogue, merchandising, search, payments and fulfilment promise are tuned against the actual query and basket mix, not a generic retail template. Multi-territory storefronts, lifestyle merchandising and subscription patterns are modelled in the platform rather than patched on top of a single storefront.
How is ERP integration handled across platforms?
ERP owns commercial data: price, stock, accounts, orders, invoices. The commerce platform reads from the ERP through governed APIs and writes orders back through monitored queues. The boundary is the most important design decision in the estate and is written down for every project.
Where does PIM sit relative to the commerce platform?
PIM owns catalogue truth: attributes, variants, assets and channel readiness. The commerce platform reads from PIM rather than re-modelling deep product data in the storefront. iWeb implements Akeneo, Salsify and Informatica alongside commerce builds where the catalogue justifies it.
How does iWeb handle replatforming?
Sequenced by domain, traffic share or territory so trading stays live throughout. Catalogue, pricing, accounts and orders are migrated against governed data contracts. Launch is rehearsed; a written rollback path exists for every step. Big-bang relaunches are rarely the right shape and iWeb will say so.
How does support after launch work on these platforms?
A named senior team owns the estate: releases, incidents, integration monitoring and platform upgrades. The runbook is written down and on-call cover is shaped to the trading window. Quarterly health reviews surface technical debt, integration drift and trading priorities for the next cycle.
How does iWeb rescue an in-flight or post-launch build?
We audit what is in production, what was promised, what is shipped and what is at risk, then write a remediation plan with sizing. The first month is deliberately conservative on change while the team learns the build. Rescue is a service in its own right, not a sales hook.
How is five-year total cost of ownership sized?
Licence, hosting, engineering, support and integration surface across the lifecycle, not just year one. The headline year-one number is rarely the honest comparison; the integration surface and operational ownership cost is usually where platforms diverge once the first 18 months pass.
Hosted, self-hosted or cloud: how does iWeb choose?
Against operating model, integration cadence, compliance posture and engineering capacity. Self-hosted Adobe Commerce, vendor-hosted SaaS and managed cloud all have honest places. The hosting decision is sized as part of the platform read rather than treated as an afterthought.
When does composable commerce actually earn its place?
When independent release cycles for catalogue, pricing, search and storefront are operationally needed; when the team can own the integration surface; and when the catalogue, trade and territory model justifies the architectural cost. Composable as a default rarely pays back; iWeb names the trade-off upfront.
How is search and merchandising handled?
Native search where the query mix supports it; specialist engines such as Algolia or Constructor.io where the catalogue depth, volume or merchandising appetite justify them. Relevance is a continuous activity with named ownership, not a launch-day setting.
How is multi-store and multi-brand handled?
Shared catalogue with brand or market storefronts, shared pricing and operations rather than parallel sites that drift apart. Per-territory tax, currency, language and compliance are modelled inside the platform; the storefront is the surface, not the rule-keeper.
Who owns the platform after launch?
A named senior owner stays through into support, with the engineering team that built the surface. Ownership does not change hands at launch; releases continue on a planned cadence; the runbook is written down and the on-call team can act on it without escalation chains.