Choosing an ecommerce platform: six different businesses, six different answers

Most advice on choosing an ecommerce platform for a small business is a ranked list of the same six products. The lists are not wrong, exactly. They are answering a question that has not been made specific enough to have an answer.

"Online store" is not one product. A single-product offer page, a multi-product catalogue, a digital download store, a productised-service store, a multi-vendor marketplace and a store-builder platform are six different businesses. They have different checkouts, different fulfilment models, different admin queues and different failure modes. A comparison table that treats them as one category will recommend the same platform to all six, and it will be right about two of them.

So this page starts with the shapes, then the counted core that is common to all of them, then the three questions that actually decide it — and an honest section on the three cases where building beats buying, because for the other three it does not.

The six shapes

1 · The single-product offer page. One thing, one price, maybe two variants. The entire product is the page and the checkout. What matters is page speed, a checkout with as few steps as possible, and payment. Almost everything else on a platform's feature list is dead weight. People routinely buy a full catalogue platform for this and then use two percent of it.

2 · The multi-product catalogue. The default assumption, and what most platforms are built for. Variants, search and filtering, stock, shipping rules, order management. If this is you, the market serves you extremely well and your decision is genuinely mostly about price and taste.

3 · The digital download store. No shipping, no stock — and a different hard problem: entitlement. Who is allowed to download this, how many times, for how long, and what happens on a refund. Add licence keys or account-based access and it diverges further. Digital tax rules also differ by where the buyer is, which is a compliance question rather than a feature question.

4 · The productised-service store. Selling a fixed-scope service: a consultation, an audit, an installation. The purchase creates an obligation and usually a scheduling step, so the "order" is the start of a workflow rather than a parcel. Most platforms handle the payment fine and have nothing for what follows.

5 · The multi-vendor marketplace. A genuinely different product. Vendor onboarding, per-vendor catalogues and stock, split payments, commission, vendor payouts, and moderation. Anyone who tells you this is a plugin has not run one.

6 · The store-builder platform. You are not selling; you are letting other people sell. That is a SaaS product with tenancy, and it belongs in a different conversation entirely.

Write down which one you are before you look at any product. If a specification does not name the shape, it silently averages all six, and the average is a product-CRUD app with a cart bolted on. That is as true of a build as it is of a purchase.

The counted core

We counted what online stores actually ship across 90 core sources — platform documentation, open-source starters, live marketplace scripts and demo admin audits — with a second pass over 72 sources on structure. Ranked by how many of the 90 evidence each capability:

Capability	Sources	Share
Product variants and options	49	54%
Customer accounts	48	53%
Order management	47	52%
Checkout and order creation	44	49%
Payment gateway integration	42	47%
Search, filter and sort	42	47%
Shipping and fulfilment	40	44%
Inventory tracking	39	43%
Reviews and ratings	35	39%

Those percentages are lower than people expect, and the reason is the six shapes. Nothing clears 70%, because the 90 sources span all six — a digital download store has no shipping and no stock, and a single-product page has no search. The absence of a universal core is itself the finding. It is the numerical version of "decide your shape first".

What each of these has to do to be real is worth a line each:

Variants — a checkout line must snapshot the variant's price and SKU. If the line points at a live product record, changing a price later rewrites history and your old orders become wrong.
Checkout — must create a durable order or payment-handoff record. An empty-cart checkout that redirects somewhere is not proof of anything.
Payment — needs server-side sessions, webhooks and idempotency, or a repeated confirmation charges twice.
Inventory — stock writes movement rows and is rechecked at order creation, not just when the page was rendered.
Reviews — genuinely optional, and the first thing to defer.

The three questions that decide it

Skip the feature grids. For a small business the decision comes down to three things, in this order.

1 · Does it fit your shape?

Not "can it be made to". Trial it with your actual products. If you sell digital goods, upload a real file and buy it. If you sell services, take a booking. If you have 40 variants across a size and colour matrix, create one product properly and see how long it takes.

2 · What does it cost at your volume?

The monthly subscription is rarely the biggest number. Model the transaction percentage at your expected turnover, then add the apps you will need — because the honest cost of most platforms is the base plus three or four extensions, and the extensions renew too.

The comparison that matters is total cost at next year's volume, not this month's. Platforms are priced so the cheap tier stops fitting at exactly the point you would notice.

3 · What does the export contain?

The single most-skipped question and the one people regret. Ask specifically whether a full export includes products, variants, customers, order history, and images — and get it before you have two years of trading in it.

A platform you cannot leave is a much more expensive commitment than the price implies, and this is the one thing you can verify in ten minutes on a trial account.

If you are moving from an existing store

Most people reading this already have a store and are unhappy with it, which makes migration the real subject. Five things break, reliably, and four of them are avoidable.

URLs, and therefore your search traffic. This is the expensive one. Every platform has its own opinion about product and category URL structure, and changing platform changes every address on the site. Without a redirect from every old URL to its new equivalent, you lose the rankings those pages had, and getting them back takes months.

Do this before launch, not after: export the full list of current URLs, map each to its destination, and confirm the new platform lets you upload redirects in bulk. If it does not, that is a serious mark against it.

Order history. Frequently the hardest thing to move, and frequently abandoned — the store launches with a clean order table and the old data sits in a spreadsheet. That is survivable for accounts and painful for customer service, who will be asked about last year's order. Decide deliberately rather than by default, and if you are not migrating it, keep the old admin readable for as long as your records obligations require.

Customer passwords never migrate. They are hashed, and correctly so. Every customer has to reset, which means a communications plan and a spike in support the week you switch. Plan the email; do not let people discover it at checkout.

Images and their alt text. Images usually move. Alt text, filenames and ordering frequently do not, and the loss is invisible until someone notices the product page has a photo of the wrong variant first.

Anything an app was doing. Every extension on the old store is functionality with no home on the new one. List them before you choose, because "we will find an equivalent" is how a migration budget doubles.

The one thing that makes all of this easier: do it while you are small. A migration with two hundred orders is an afternoon. The same migration at twenty thousand orders is a project, and the decision not to move at year two is usually what commits you for another five.

Buy first — genuinely

For shapes one, two and four — the offer page, the catalogue, the productised service — a hosted platform is almost always the correct answer for a small business, and it is worth saying that plainly on a site that sells build specifications.

The reasoning is unsentimental. Payments, fraud handling, PCI scope, tax calculation, deliverability and uptime are all solved, maintained by somebody else, and expensive to get wrong. A small catalogue business that builds its own store is taking on a permanent maintenance obligation to save a subscription that is smaller than one order a week.

Buy, and spend the effort on the things a platform cannot do for you: your photography, your descriptions, your delivery promise and your returns policy.

The three shapes where building is honest

That said, three of the six are genuinely poorly served, and in these the arithmetic changes.

The multi-vendor marketplace. Marketplace extensions to consumer platforms are consistently the weakest software in this category, and dedicated marketplace platforms are priced for funded businesses. If you are building a marketplace, you are building a product, not a shop — and that is a build.

Unusual entitlement or subscription models. Digital goods with licence rules, seat-based access, metered usage, or a subscription that is not simply "the same box every month". Platforms model one subscription shape well and everything else badly.

B2B and wholesale. Customer-specific pricing, quotes, purchase orders, approval chains and account-scoped catalogues are structural, not add-ons. This is the strongest build case in the category and it has its own page.

There is a fourth, quieter case: you already sell through a platform and the thing that does not fit is one part — usually fulfilment, or a configurator, or a pricing rule. Building that one piece against the platform's API is far more sensible than rebuilding the store, and it is the option nobody presents because it does not fit either sales pitch.

If you build, the correctness list

Three storefronts were built from a single specification by three coding models, each run to full scope, and each independently selected 15 of the 21 available features — setting aside exactly the six umbrella branches the research says belong outside a normal store. That convergence is the useful part: when the scope decision is made explicitly, capable models agree on what a store is.

All three take a real order end to end, and all three kept payment in an honest test mode, which is the correct behaviour when no live credentials exist. What separated them was correctness, and this is the list worth stealing:

Returning to a paid checkout page never charges twice. A repeated confirmation is recognised and ignored.
Two shoppers cannot both buy the last item. A database guarantee, not a check in code.
Stock only leaves the shelf once payment actually succeeds.
Price authority is enforced everywhere a price can enter — including spreadsheet import, which is the door that gets forgotten. In one build, catalogue staff could change prices by importing a file, while the same permission was correctly enforced in the interface.
A cancelled order cannot then be shipped, refused on the server.
Accepting a return does not automatically restock or refund. Separate decisions.
Unpaid cash-on-delivery orders are not counted as money received.
A discount recalculates tax on the reduced price, not the original.
Customer data is owner-scoped. In one build the customer list — names, addresses, order history — was readable by catalogue and warehouse staff, contradicting the build's own permissions table. The table was right and the code had not followed it.

Nine properties, none of them a feature, and every one of them is what separates a store that takes money correctly from one that looks like it does.

The checklist

Name your shape. Write down the five you are not.
Create one real product with your actual variant structure.
Buy it. Then reload the confirmation page and check you were not charged twice.
Have two people buy the last unit at once.
Refund it. Check what happened to stock, separately from what happened to the money.
Apply a discount code and check the tax.
Export everything. Confirm order history and images are in there.
Add a staff member with limited rights, then try to reach the customer list as them.

If you are selling to businesses rather than consumers, B2B ecommerce platform covers the seven things a consumer store cannot do. If search is how you expect customers to find you, best ecommerce platform for SEO covers that axis. And if stock turns out to be the harder half of the problem, what a retail inventory management system includes is the counted inventory for it.

If you are building, the Online Store planner is the specification we hand our own agents — the store shape locked before anything else, and the checkout, stock and price rules above written in so an agent has to build them rather than produce a catalogue and a cart.