Ecommerce builds that start with the platform decision

Start from your actual constraint. If merchandising and campaign pages are slow to produce and the front end is where you are blocked, headless addresses that directly. If your problem is pricing logic, complex B2B rules or ERP behaviour, headless changes nothing and adds cost.

Shopify handles a very large share of real-world commerce well, including substantial catalogues, and it removes an enormous amount of infrastructure work. The reasons to leave it are usually specific: unusual pricing models, deep ERP coupling, regulatory requirements, or a content operation the theme layer genuinely cannot serve.

Integrations first, catalogue complexity second, and the storefront third. A visually ambitious storefront on a simple catalogue with no back-office integration is a comparatively small project. A plain storefront wired into an ERP, a warehouse system, a tax engine and a PIM is not.

The reason integration costs surprise people is that the happy path is quick to build. The remaining work is what happens when the ERP is down, when stock changes mid-checkout, when a sync partially fails, and when finance needs to know which of the two systems is authoritative.

Largely, if the migration is planned properly. Ecommerce replatforms carry more risk than marketing-site migrations because URL patterns for products, variants, categories and filters usually change all at once, and there are far more of them.

The work is a complete URL inventory, a redirect map covering discontinued products as well as live ones, preserved category structures where they have earned rankings, and structured data carried across intact. Discontinued products in particular should redirect to a sensible parent category rather than disappearing.

Deliberately, and early. Decide what is a distinct product and what is an option on one, because that decision drives URLs, filtering, stock display, feed quality and how much work a price change costs your team.

The common failure is treating colour as a separate product when customers search by style, or as an option when customers search by colour. It depends entirely on how your buyers shop, which is worth establishing from search behaviour rather than internal habit.

Usually yes, and rarely by making the images smaller. The typical causes are unbounded faceted navigation generating enormous numbers of crawlable combinations, filtering done client-side over a large dataset, and category templates that load every product variant to render a price.

Fixing it means constraining which facet combinations are indexable, moving filtering server-side, and rendering the parts of the page that matter without waiting on the full catalogue query.