How to choose an e-commerce platform

Almost every proposal for an online shop looks the same: a platform name, a feature list, a price. What proposals almost never contain is why that platform, and what happens in two years. That is odd, because the platform decision is one of the few that is genuinely painful to reverse later.

In short

• The feature list does not decide it: nearly every platform can sell. What differs is what they let you do when your process is not standard.
• The most important question is not technical: who will handle orders, products and returns every day.
• The second is where stock and invoices live. If not in the shop, the real work is integration rather than the shop.
• You will most likely change platform eventually. So data portability matters more than initial convenience.
• Migrating an existing shop costs more than building a new one — because of URLs, product history and customers.

Five routes, not five brand names

We deliberately name no platforms. Recommending one without knowing your operations is marketing rather than advice: the same name is right for one shop and wrong for another. The routes, however, differ fundamentally — and once the route is settled, choosing a name is straightforward.

• A content system with a commerce module. Fits when content matters more than the catalogue and there are few products. The limit appears when serious stock or pricing logic is needed.
• A dedicated commerce platform. Fits a larger catalogue and a conventional checkout. The limit is a non-standard process: the platform has its own opinion about how things should work.
• A hosted service. The fastest start and the least maintenance. The limit is a monthly fee that grows with volume, and only the changes the platform permits.
• A custom build. Fits when the selling logic is the essence of the business. The limit is cost and the need for continuous upkeep; without it, it becomes an ageing system.
• Migrating an existing shop. A separate route rather than an option: the question here is not which is better but how not to lose what already earns.

The question that decides the most

Not "which features do we need" but "who will work with this daily". A shop is not a project that ends at launch; it is daily work — descriptions, prices, promotions, returns, customer questions. If one person will do it between other duties, the platform needs to be boring and obvious. If there is a dedicated team, you can choose flexibility that has to be learned.

A practical test: ask the supplier to show you adding a new product with two variants and photographs. Not a presentation — the actual action in the admin interface. Those few minutes will tell you more about the platform than any feature list.

Where stock lives

If stock levels and invoices already live in an accounting or warehouse system, the weight of the project is not in the shop. Then the questions are which system is right about the quantity, what happens when they disagree, and how quickly they must agree. Those are integration questions rather than shop questions, and they frequently cost more than the shop itself.

The worst arrangement is two stock figures, both edited by hand. It works until the first sale, and then somebody sells something that does not exist.

What proposals usually leave out

• VAT and invoices: who issues them, whether the shop or the accounting system does it, and how different countries are handled.
• Returns: not a button on the site but a process — who approves, who refunds, when stock reappears.
• Deliveries: how a method is chosen, who prints labels, what the customer is told about timing.
• URL structure: it determines whether you can change platform later without losing visibility.
• Photographs and descriptions: usually the most realistic source of delay, because the client has to produce them.

Migration costs more than a new shop

This is counterintuitive, so it is worth stating plainly. A new shop is a blank page. A migration has to preserve product URLs, customer accounts, order history and often years of accumulated search visibility. Each of those is separate work with its own risk, and a mistake in URLs is not noticed immediately — it shows weeks later, when traffic drops.

Illustrative scenario, not a description of a client project

Imagine a shop choosing its platform on which admin interface felt most comfortable. A reasonable basis, until it turns out that business customers need contract pricing. The platform does not do that, and the only workaround is manual handling of every such order. There was no technical mistake — the selection criterion simply was not the one that decides. So the process is described first and the platform chosen after. This is an example of how we weigh the choice, not a promise about a particular outcome.

What to prepare before talking to suppliers

• Write down who will handle products and orders daily, and how much time they have for it.
• Answer where stock and invoices live today.
• List three ways your selling is not standard. If there are none, that is good news and a cheaper project.
• Decide whether you will produce descriptions and photographs, and when.
• Ask every supplier to explain how data can be taken out of their solution later.

With that list in hand, choosing a platform stops being an argument about opinions. Usually two routes remain, and the difference between them is visible.