How to choose an e-commerce platform starting from your company's needs

Choosing a platform to sell online is almost always approached backward: you start from the names and look for the best one. There is no best one. There's the one that can handle your catalog, your processes, and the people who'll use it every day. This guide helps you build your requirements before looking at solutions, and verify them with a trial instead of a feature list.

The cost of a wrong choice isn't paid in the first month. It's paid the day you need something the platform doesn't do and can't be added: at that point every alternative is expensive.

What it needs to do, not what it is

Requirements are written by looking at what happens in the company, not at software product sheets. Five areas cover almost everything.

• The catalog: how many products, how many variants per product, how many images and documents, how often prices and availability change, whether there are configurable or made-to-measure items.
• Prices: whether they're the same for everyone or depend on the customer, whether there are reseller price lists, quantity tiers, different tax rates by category, different currencies.
• Orders: how an order comes in, who checks it, what happens if the product isn't in stock, which documents are needed, whether some orders originate outside the website.
• People: who uploads products, who responds to customers, who handles shipping, and with what skill level. A hugely powerful platform managed by no one produces a stagnant catalog.
• The systems already in place: business management system, warehouse, accounting, couriers, marketplaces. These are the hardest constraint, because they don't get changed to make the website happy.

Must-haves and nice-to-haves, separated in writing

Every requirement goes into one of exactly two groups: without this we can't work, and this would be nice to have. The second group tends to swell and push the choice toward solutions more complex than necessary.

A must-have requirement needs to be written in a verifiable way. "It must handle variants well" can't be tested. "A product must be able to have size and color with a different price and availability for each combination, and inventory must decrement per combination" can be tested in half an hour.

The trial, instead of the feature list

Comparison tables say everyone does everything. The way out is to test, with your own data, the case that makes your life complicated.

1. Take three real products, chosen among the trickiest: the one with the most variants, the one with a changing price, the one with attached documents.
2. Actually upload them, doing the work the person in charge of it will do. Count the steps.
3. Complete a full order, including the case that's a headache for you: product out of stock mid-order, delivery to another country, customer with a reserved price list.
4. Test the most critical integration in a test environment, not on paper. If a test environment doesn't exist, that's already telling you something about the solution.
5. Note down what you weren't able to do and what you had to ask for help with. These are the two columns that will matter most a year from now.

The evaluation matrix

The matrix is there to make what you've seen comparable, not to produce a score to show in a meeting. Each row should be filled in with the date of the check and the plan you tested it on: commercial terms change over time, and a note taken a few years ago may simply be false today.

The cost that doesn't show up in the subscription

• The additional modules needed to get what you require, and their maintenance every time the platform updates.
• Transaction fees, where they apply: they grow with revenue while the subscription stays the same.
• Internal time: uploading products, managing orders, responding to customers. It's the biggest cost, and the only one that doesn't appear on any quote.
• Dependency: how many people are able to work on that solution, and how tied you are to a single vendor for every change.

Leaving and growing

Two questions need to be asked before signing, because the answer doesn't change afterward. The first: if we wanted to leave in a few years, what could we take with us? Products, customers, orders, and content need to be exportable in a readable format, not just visible on screen.

The second: what happens if the catalog doubles, if we add a language, if we open sales to resellers with reserved prices? You don't need definitive answers; you need to know whether these are anticipated changes or rewrites.

What this guide doesn't cover

Here solutions are compared against your requirements, with no absolute rankings: no platform is the best in the abstract, and every feature needs to be verified on the plan you'll actually buy, on the date you buy it. Whether the company is ready to sell online — who packs the boxes, who responds, who keeps the catalog updated — is a question that comes first and is covered separately, as is the connection between the store and the warehouse.