Choosing an e-commerce platform, and the work that actually decides whether it sells

Most platform comparisons are a feature table with a column of monthly tiers, and they are close to useless, because every serious platform can display a product, take a card and email a receipt. Nobody loses money because their platform couldn’t render a category page.

The decision is made somewhere else, by four constraints that are properties of your business rather than of the software. Get those right and several platforms will work. Get them wrong and no platform will.

Constraint one: how complicated is the catalogue, really

This is the one that most often forces the answer.

A hundred products with a size and a colour is a simple catalogue. Configurable products with dependent options, per-customer pricing, unit-of-measure conversions, kits and bundles, serialised items, products sold by length or weight, or the same item priced differently by channel; those are not the same problem, and platforms differ enormously in how gracefully they handle them.

Write down your five most awkward products before you evaluate anything. Not your best sellers, your most structurally awkward ones. If a platform can’t express those cleanly in a demo, it will be expressed as a workaround for the life of the store, and workarounds in a catalogue leak into pricing, search, feeds and reporting.

Constraint two: where fulfilment and stock actually live

If you have an ERP, a warehouse system or a 3PL, the store is not the system of record for stock, price or the customer. It’s a read model with a refresh interval, and the interesting question is how well the platform tolerates being told what to think.

Decide, per entity, which system holds the truth and which is allowed to change it. Then decide how stale is acceptable for each. Stock from five minutes ago is usually fine; credit status at checkout usually isn’t. Writing those tolerances down turns an argument into a design input, and it’s a better predictor of whether the store works than any feature list.

Constraint three: who operates it on a Tuesday afternoon

Platforms distribute operational load differently, and the honest question is who absorbs it.

A hosted platform takes hosting, patching, security updates, PCI scope and uptime off your desk and puts limits on how deeply you can change behaviour. A self-hosted platform gives you the source and hands you the responsibility for keeping it current, which is fine if you have someone whose job that is, and a slow-motion incident if you don’t.

The failure we see most often is a self-hosted store with a deep customisation layer, three major versions behind, where upgrading is impossible because nobody knows which modification breaks. That’s not a platform failure. It’s an operating-model decision that was never consciously made.

Constraint four: is any of this B2B

Most e-commerce platforms are B2C-shaped by default and get B2B bolted on. If you need customer-specific catalogues and pricing, account hierarchies, quotes, purchase-order payment, credit terms, order approval workflows or reordering from history, treat that as a first-class requirement rather than a phase two. It changes the shortlist.

Churpi is the shape this takes in practice: a PrestaShop build with product and price configuration and both a B2C storefront and a B2B portal, running alongside each other. Two audiences, one catalogue, different rules. That’s an architecture decision, not a theme choice.

So which family fits

With those four settled, the landscape sorts itself:

Hosted commerce platforms suit teams who want to run a store rather than run software, with a standard-shaped catalogue and a preference for extending through apps rather than code. You trade depth of control for not owning the operational burden.

WordPress with WooCommerce suits businesses where content and commerce are genuinely intertwined and marketing already lives in WordPress. Enormously extensible, and the extensibility is the risk: plugin sprawl is the default failure mode, and every plugin is a dependency you now maintain.

PrestaShop sits in a useful middle. Open source, so you have the code; a mature module and template ecosystem; and native multi-store and multi-language management from one back office, which matters if you operate several storefronts or sell across languages and want them administered together. It’s straightforward for a non-technical team to run day to day (catalogue, orders, shipping, payments), and it produces reasonable URL and metadata structures without much intervention. The trade-off is the one common to self-hosted platforms: you own the upgrade path, and module quality varies, so a module audit belongs in your maintenance routine rather than in an emergency.

Enterprise-grade open source suits genuinely complex catalogues, multiple brands and heavy customisation, and demands the engineering capacity to match. Choosing it without that capacity is the most expensive mistake in this category.

Site-builder commerce is fine for a small, simple catalogue and stops being fine at a fairly predictable point. Know where that point is before you’re near it.

Building it is justified when commerce is embedded in a process the products don’t model: availability, booking, configuration, marketplaces. MyGlampings is that shape: a booking platform with availability, reservations, payments and semantic search, where the state problem is the product.

Now the part no platform does for you

Platform choice takes a week. Everything below determines revenue for years, and it’s identical whichever you pick.

Be unambiguous about what you sell, immediately. A visitor decides whether to stay in a few seconds. If the landing page requires interpretation, the rest of the funnel is theoretical.

Reduce the checkout to the fewest steps that still work. Offer guest checkout. Forced account creation is the most reliably self-inflicted abandonment in e-commerce. Offer the payment methods your customers actually use, and show total price, including shipping and tax, before the final step, because unexpected additions at the end are the other reliable one.

Give products enough information to decide from. Real photography at real resolution, dimensions and materials, what’s in the box, stock truth, delivery expectation, returns terms, and reviews. Most abandonment is unanswered questions, and every unanswered question is also a support ticket.

Make search work. On any catalogue past a few hundred items, internal search is a primary navigation tool and usually the worst-performing part of the site. Zero-result queries are a free list of what customers want and can’t find.

Be fast, particularly on mobile. Speed isn’t a design trend, it’s a conversion input and a ranking one. Image handling, script count and caching account for most of it, and a new theme is entirely capable of being slower than the one it replaced.

Answer people in the moment. Live chat or a well-bounded assistant resolves the small blocking questions (sizing, compatibility, delivery) that otherwise end the session. Give it a clean handoff to a human.

Keep serving after the sale. Dispatch clarity, straightforward returns, and a follow-up that isn’t only promotional. Retention is where store economics are actually won, and it’s mostly operations rather than design.

Which “design trends” are worth the money

Some of the perennial list is durable, some is decoration.

Worth it, always: mobile-first layout, touch-appropriate navigation, real speed work, and enough restraint in the design that the product is the loudest thing on the page. Minimalism isn’t an aesthetic here; it’s the absence of things competing with the buy button.

Worth it, conditionally: personalisation, if you have enough behavioural data for recommendations to be better than a merchandiser’s judgement, and a data model that can support it. Done well it’s a genuine lift; done thinly it recommends the thing someone just bought. SalePops is an AI-personalised discovery app built for exactly this problem, and the hard part was never the interface.

Worth it for specific categories: AR and 3D visualisation, where the buying objection is spatial or fit; furniture, eyewear, large equipment. If your customers aren’t asking “will it fit” or “what does it look like on me”, it’s an expensive demo.

Rarely worth it: gamification, unless you have a genuine repeat-purchase or loyalty mechanic for it to attach to. Points on a considered one-off purchase are noise. Video is the reverse: consistently underused, and a thirty-second product-in-use clip outperforms most redesigns.

If you’re moving from an existing store

Two things, and both are covered in more depth in our guide to replatforming without losing search traffic: the redirect map is the project, not a task at the end of it; and don’t replatform, redesign, rebrand and restructure the catalogue at the same time, because if traffic falls you’ll have four candidate causes and no way to isolate any of them.

We’ve run migrations where preserving search positioning was the explicit deliverable: Zeta Zepo’s full WordPress move, and Deren’s WordPress and Elementor migration, which kept the existing calls to action and had measurement installed as part of the migration rather than afterwards.

The five questions to take into any demo

• Show me my five most awkward products, modelled properly.
• Which system owns stock, price and the customer, and how stale can each be?
• Who patches this, and what happens when a module blocks an upgrade?
• What does B2B look like here: is it native or bolted on?
• What do I need to redirect, and who owns that map?

We’ve built and integrated stores on PrestaShop (Churpi, with both a B2C storefront and a B2B portal), migrated sites to WordPress with search positioning as the point (Zeta Zepo, Deren), and built commerce-shaped platforms from scratch (MyGlampings). If you’re choosing or replacing a platform, tell us what your catalogue looks like, starting with the awkward products.