Which ecommerce platform? Criteria, not rankings

There is no best ecommerce platform, only one that fits a specific business, and that fit is settled by a handful of criteria rather than a spot in a ranking: catalog complexity, B2B needs, the ownership-versus-rental calculation, ERP integrations, control over checkout and data, architecture (headless or monolith), the team that will run it, readiness for visibility in AI, and the risk of the migration itself. If you already know you are switching platforms and you are asking “to what”, this article will not hand you a list of names to copy. It gives you a framework to judge which kind of platform fits your profile, and when the honest answer is “stay on SaaS”.

Why a “Top 7 platforms” ranking is a bad map

A platform ranking answers a question no one sensibly asks: “which platform is best for everyone at once”. That platform does not exist, because the needs of a store with a thousand simple D2C products and a B2B wholesaler with per-customer pricing and ERP integration have little in common. A “Top 7” list usually mixes tools from different worlds, rates them on features detached from your context, and stays silent on what actually hurts after two years: the exit cost, integration limits, the availability of people to build with. So instead of asking “which platform is best”, ask “which criteria are decisive in my case, and how does each kind of platform score on them”. The rest of this article is those criteria.

Three platform families (plus fully custom)

Before the criteria, it helps to know the kinds you are choosing between, described by type, not by brand:

• Hosted SaaS: the vendor gives you a ready platform on a subscription and keeps the infrastructure (examples of the kind: Shopify, BigCommerce).
• Open-source / self-hosted: the code is open and free, but deployment, hosting and maintenance are on you or a partner (WooCommerce, PrestaShop).
• Headless / composable: the commerce layer is separated from the front end and assembled from components over APIs (Medusa, commercetools).
• Fully custom: a platform built for one specific business, when no ready-made option fits.

This is not a ranking from worse to better, but four different trade-offs between control, cost and speed. I name products only to illustrate a kind, not as a recommendation or a rating.

The nine criteria below are a list worth walking through with your own business in hand. For each I give the question to ask yourself and what the answer actually settles. I grouped them into three blocks: data and sales model, technology and control, and people and risk.

1. Catalog and variant complexity

Question: how many SKU do you have, how deep are the variants and attributes, do you need configurators, technical files, made-to-measure products?

What it settles: a simple catalog of a few hundred products fits the standard of any SaaS and is not an argument for anything pricier. Thousands of items with rich variants, technical attributes, configuration-dependent prices or downloadable files quickly hit the data model of a boxed platform. This is the first threshold that pushes the choice towards platforms with a richer product model or towards a custom solution, where you design the data model for your assortment rather than for its intersection with the market average.

2. B2B needs

Question: do you also sell to businesses, and if so, do you need per-customer pricing, contract discounts, order approvals, credit limits, quick ordering by code and net prices?

What it settles: full B2B logic rarely fits the standard of a D2C SaaS. Either you add expensive apps that still do not do everything, or you pick a platform with a native B2B module, or you build it yourself. If wholesale is a meaningful share of revenue, treat B2B as a first-order criterion, not an add-on. We break down the architecture of that kind of selling, including writing orders back to the ERP, in the separate piece on B2B store and ERP integration.

3. Ownership versus rental and the TCO calculation

Question: do you want to rent a platform on a subscription, or own an asset (code, data, integrations), and what does total cost of ownership over three years say?

What it settles: this is a decision about the character of the cost, not just the amount. SaaS is a low start cost plus a percentage of revenue that grows with every good month. Ownership is a higher build cost and flat, predictable upkeep. You cannot settle it with a price list, only with a TCO calculation for your numbers, which we work through step by step in the separate article on the cost of owning a store. This criterion often tips the scale when the others come out even.

4. Integrations: ERP, WMS, PIM and the rest of the stack

Question: which systems must the platform talk to (ERP, warehouse, PIM, loyalty, marketplaces) and by what route (modern API, an exchange service, files)?

What it settles: this is the most common place where a boxed platform says “no further”. API limits, missing webhooks, no access to the layer you need to integrate can overturn a project that looked simple on paper. Open-source, headless and custom platforms give you freedom here, paid for with complexity. If integrations are the heart of your operation, check each candidate’s API limits before you look at its marketing page.

5. Control over checkout and data

Question: on this platform, can you change the checkout steps and fields the way your process requires, and can you export your data without loss if you ever have to leave?

What it settles: a closed, untouchable checkout is one of the most expensive constraints, because the sales lost on it are nearly invisible in reports. We wrote separately on how to audit a checkout in ten points; if a platform will not let you fix any of them, that is a real business limitation, not cosmetics. The same with data: a lossy export turns customer and order history into a hostage of the platform and raises your future exit cost. Control over checkout and data is a criterion easy to miss in a demo and painful for years.

6. Headless or monolith

Question: do you genuinely need to separate the front end from the back end, because you have many sales channels, demanding performance or a fully custom design, or are you drawn to headless because it sounds modern?

What it settles: headless gives front-end flexibility and multichannel reach, but costs complexity that someone has to maintain. A monolith (a unified front and back end) is simpler and cheaper to run and sufficient for many stores. This is the criterion where it is easiest to overpay for fashion: headless without a concrete business reason is expensive flexibility nobody uses. Choose headless when you have a named problem it solves, not just in case.

7. Team and maintenance after launch

Question: who will run this platform after launch, do you have your own developers, will you buy maintenance from a partner, or do you want to offload it onto the vendor?

What it settles: a platform you have no one to maintain is a bad choice no matter how good it is technically. SaaS moves infrastructure maintenance to the vendor, and that is its real advantage. Open-source, headless and custom solutions require constant care, your own or bought as a service. Answer honestly how much technology you want and can take on, because this criterion filters the list harder than most product features.

8. Readiness for visibility in Google and AI

Question: does the platform give you control over structured data, server-side rendering, speed and metadata enough for the brand to be well visible in Google and in AI answers?

What it settles: visibility in search and in generative systems depends, among other things, on a clean page structure, correct structured data and performance, and you need control over those. Closed platforms can be limited here by architecture and plugins. A plain caveat: no platform guarantees a position in Google or citation by AI, these are variables no one controls. A platform can, however, either ease that visibility or stand in its way, and that is what you are asking about.

9. The risk and cost of the migration itself

Question: how much risk does the specific target carry, is it mature, does it have a healthy ecosystem and available builders, and can you ever leave it without drama?

What it settles: the prettiest platform on paper is a bad choice if there is no one to build with, or if in two years you hit a dead end with no exit path. Add the cost of moving data, content and SEO rankings, which has to be counted for each candidate. How to run the move itself without stopping sales we cover separately; here it is about the earlier decision, so you do not migrate into a place from which the next migration will be even more expensive.

When the honest answer is: stay on SaaS

Not everyone needs to build their own, and we say so plainly, even though we build owned platforms. If your catalog and processes fit the standard of a boxed platform, revenue is not high, you have no hard B2B or integration needs, and the checkout in its current form is enough, then SaaS is the rational choice and there is no point forcing an exit. Migrating to a pricier solution “because the bigger players do” is premature optimisation. We gathered the signs that a store has genuinely outgrown SaaS in a separate piece; until you see them, the cheapest good decision is often to change nothing and redo the calculation in a year.

And when the criteria say build: how we do it

If walking through these nine criteria leads you to an owned platform, that is where we come in. Seedlight builds ecommerce platforms with the BEAM framework, deliberately to remove the very pains that surfaced above: a flexible data model for your catalog and B2B logic instead of fighting a box, control over checkout and integrations instead of API ceilings, and delivery in a fixed, controlled scope, fast, instead of an open-ended project. We design the platform to scale with revenue, rather than to cost more with every good month.

We add two things usually weighted too lightly when choosing a platform: automation and maintenance. AI comes in as a layer inside the platform and takes manual work off sales and catalog management (descriptions, translations, feeds, listing checks), and after launch we take on maintenance and growth, so a platform you have no one to run does not become your problem. That is a direct answer to criterion seven (team) and nine (risk), not a promise that everything runs itself. And we hold to the paragraph above: if the criteria say “stay on SaaS”, we will tell you plainly, rather than selling a build you do not need.

Choosing a migration target is not a tournament won by one name, but a fit between a few criteria and one specific business. Walk through the nine questions in this article with your own numbers and the shortlist narrows on its own, often to a single kind of platform, before any name is even spoken. In our case the decision is made exactly this way: during the Blueprint, where we test the criteria against your data and the arithmetic, and only then does a target recommendation come out, not the other way around.