eCommerce Platform and Experience Consulting

We will not answer that from a feature list, and be careful of anyone who does. The decision is usually settled by four things that have nothing to do with the comparison chart: what your ERP expects and how well it integrates, how your catalog behaves at your size, who maintains the store after launch, and what the platform cannot do that you will need in year two. We have worked across several platforms for a decade and the useful advice is always specific to those four answers.

No, and that is deliberate. We are not a development shop and we do not resell licenses, which means we have nothing to gain from recommending one platform over another. We advise, we help you brief and judge the implementation, and we work alongside whoever builds it. If you need a build partner we can point you at ones we have worked with and tell you honestly what each is good at.

The specific things that are not in the documentation because they are not faults. Structured data emitted as microdata rather than JSON-LD. A hard character limit on a field you needed more room in. Prices and stock rendered after page load, so automated checks report confident nonsense. Several paths to the same category, each claiming to be canonical. No permanent removal status for deleted products. Accents dropped from URLs. A template split where a feature appears on one page type and silently not on another. Each of those changed a recommendation we would otherwise have made.

Not at the connector, which is the part everyone worries about. It goes wrong at ownership: two systems each think they own the price, or the description, or the stock figure, and nothing defines what happens when they disagree. You find out months later when a product on the store contradicts the product in the ERP and nobody can say which is right. Deciding that map before anything is built is most of the work and almost none of the budget.

Sometimes, and less often than PIM vendors suggest. A PIM is genuinely valuable when you have multiple channels consuming the same product data and a real volume of attributes to manage, and we have consolidated two catalogs and tens of thousands of products into one after an acquisition. It is the wrong answer when the real problem is that nobody owns product data internally. Software does not create an owner, and an unowned PIM decays faster than a spreadsheet.

Substantially, and it is the question most platform conversations skip. Once there is more than one store the decision stops being which platform and becomes what must be identical across them and what must genuinely differ. Pricing and terms usually differ. Product facts usually should not. Get it wrong one way and you maintain everything twice. Get it wrong the other way and the same product is described two ways, which teaches machines that one company is two. We work across 32 storefronts in both architectural models.

Often they are describing a velocity problem rather than a platform problem. They cannot change the storefront without developer time, so campaigns queue and land late. Replatforming is an expensive way to fix that, and it frequently does not. The honest sequence is to work out whether the blockage is the platform, the templates, or the process and ownership around them. Sometimes an experience layer on top of the existing stack solves it in weeks. Sometimes the fix is nobody having to ask a developer for a banner.

It is a content and storytelling platform that sits above an existing commerce stack, so marketing teams can build and publish experiences without a development release. We have a commercial relationship with Live Story and we will say so before we recommend anything, because you should weigh that. What we will not do is diagnose backwards from a product we can earn on. The diagnosis comes first, and often it concludes that no new software is needed.

More companies have built their own middleware than admit it, and it usually exists because a real need went unmet, which makes it evidence rather than embarrassment. Whether to keep it is a maintenance question: who understands it, what happens when they leave, what it costs to keep current, and whether a supported product now does the same job. Sometimes the answer is keep it. The point is to decide deliberately rather than by inertia.

This is about decisions concerning the platform: choosing it, integrating it, structuring it, knowing its limits. The SEO work is what happens on the platform once you have it: catalog, structure, schema, feeds, visibility. Different questions, different moments. If you already have a platform and need it to perform, that is ecommerce SEO. If you are choosing, integrating or wondering whether to move, that is this.