How to Choose an Ecommerce Platform: A Decision Framework

In ecommerce projects the first decision made is the platform decision, and it is usually the one made with the least information, too. Before anyone knows how many products will be sold, how many variants there will be, which marketplace the store will connect to and who will run the work, a panel gets picked; the next two years are then shaped by that panel's limits.

Part of the problem is where the information comes from. Most of the Turkish-language content answering this question is written by a party that sells a platform, so what you are reading is not a comparison table but a text steering you towards one choice. As far as we measured, there is little text content at all for queries in the "e-ticaret altyapısı nasıl seçilir" (how to choose an ecommerce platform) family; most of the results are videos.

What follows does not recommend a platform, and cannot: the right answer changes from one business to the next. What it covers is which variables the decision should rest on, which costs do not show up in the monthly fee, and in which situation putting the decision off is the better call.

Why "the best platform" is the wrong question to ask

"Which one is best" has no answer, because the question carries no context. The same software can be far too heavy for a boutique with three products and not enough for a wholesaler with thirty thousand. Both use the same product, and both are rightly unhappy with it.

The decision is not a brand preference but a fit check: does the business's workload today, and twelve months from now, sit within what the chosen software can carry comfortably? To run that check, the numbers on your own side have to be written down first; looking at panel demos without them makes every demo look convincing.

A second warning: the choice is presented as a one-off decision, but in practice it is a lease. The cost of switching platforms grows along with the product data, URL structure and order history you accumulate on it. That is why one of the questions to ask on day one should be "how do I get out of here".

The five variables that decide it

Before building the decision table, five numbers need to be written down. Together they narrow the platform family considerably.

Number of products and rate of change. A hundred products and thirty thousand products are not the same management load. But the number that really decides things is not the product count itself; it is how many products change price, stock or description each month. Bulk editing and import capabilities matter in proportion to that number.

Variant depth. The number of options such as colour, size, material and pack quantity, and how they tie into stock, runs into a hard limit on some platforms. The catalogue decision itself is a separate subject; we went through it in detail in our article that weighs the catalogue decision and its three outcomes.

Number of sales channels. Only your own site, marketplaces as well, in-store sales too? As the number of channels grows, managing stock and price from one place becomes a necessity.

Team. Who will use the panel day to day, and where will technical support come from? This is the variable most often skipped, and the one that ends up costing the most later.

Integration list. Accounting, shipping, payments, marketplaces, email and, if there is one, an ERP. Writing the list before the choice is far cheaper than writing it after.

Hosted package, open source and custom development

There are three families, and all three do the same job with a different trade-off.

Hosted package (software as a service). Server, updates and security sit with the provider, and setup is quick. In return, your room to intervene is limited: how far you can touch the page template, the URL structure and, in some cases, the structured data output is as far as the provider allows. Where that limit lies needs to be asked in writing before you buy.

Open source. The whole codebase is yours, and your room to intervene is wide. In return, server, updates, backups and security are your responsibility. The software itself may be free, but the cost of running it is not zero; without a technical owner to carry that cost, open source produces risk rather than advantage.

Custom development. Defensible only when there is a business model standard software cannot handle: unusual pricing, a complex membership structure, an order flow unique to the business. For a standard store, custom development usually means solving from scratch problems that off-the-shelf software has been solving for years.

Costs not included in the monthly fee

Comparison tables are usually built on the monthly fee, yet a large share of the total cost never appears on that line. Without giving figures, it is possible to list which items need to be asked about separately.

• Theme and design. A ready-made theme or customisation, and how much labour it takes to adapt it to the brand identity.
• Plugins. Functions missing from the base package may be charged individually; give every item on your requirements list its own line.
• Transaction fee. Some packages take a share tied to sales volume; as volume rises, this item outgrows the monthly fee.
• Commissions on the payment and shipping side. These belong to the provider rather than the platform, but they still go into the total cost.
• Migration labour. If you are moving from an existing store, data transfer, URL mapping and testing are a separate item.
• Maintenance and updates. With open source this item is yours, with a hosted package it is the provider's; when comparing the two in one table, that difference has to be stated.

When building the table, the right question is not "how much a month" but "what will we have paid in total after twelve months, and which part of that figure depends on sales".

One more distinction helps: do not add fixed items and volume-linked items together on the same line. Fixed items can be budgeted; volume-linked items grow as sales grow and can, at some point, flip the result of the comparison. Two candidate platforms can look close at low volume and pull clearly apart at high volume; that is why the comparison should be made not with today's volume but with at least two volume scenarios.

What your team can actually manage day to day

A platform is only as good as what the person using it can do. The gap between what the panel technically supports and what the team can actually do is where projects quietly stall.

There is a practical test: during selection, ask the person who will use the panel every day to do three tasks in the demo environment. Add a new product with its variants, set up a promotion, and process a return on an order. If those three tasks cannot be done without help, the platform is expensive for that team; the gap gets closed by buying outside support, and that is a cost item as well.

A second check is where the work stops when someone is away. If the panel stands on configurations only one person understands, there is a fragility that has nothing to do with the platform. Whether to run the work in-house or hand it to an outside party is a separate decision; we laid out the framework for it in our in-house team or agency decision matrix.

Integration inventory

If the integration list is not drawn up before the choice, every gap that surfaces afterwards means either manual work or extra development.

Accounting and invoicing. How an order turns into an invoice, and where the e-Arşiv and e-Fatura flow (Turkey's electronic invoicing systems) runs from.

Shipping. Which carriers have ready-made connections, whether shipping labels can be printed from the panel, and whether delivery status goes back to the customer automatically.

Payments. The virtual POS decision sits with the bank and the payment institution, not the platform; the platform only tells you which providers it has ready-made connections with.

Marketplaces. Whether stock and price can be managed from one place. The same product sitting in two places at two different prices is one of the most tedious data problems to fix after the fact.

Product data output. How the feed files sent to advertising and shopping channels are generated, and which fields can be carried into them. The quality of this output shows up directly in the number of products rejected by shopping channels.

Can you get your data back?

Exit cost is the subject nobody raises at the buying stage, yet it produces the most expensive outcome. The questions to ask are short and clear.

Can product, category, customer, order and review data be exported in full; in what format, and which fields go missing? Can images be downloaded at their original resolution? Is the URL structure tied to a provider-specific pattern; can product URLs be kept when you move?

There is one more question on the order and customer data side: when this data can be exported, what form does it arrive in, and does it carry enough detail for returns, warranty or accounting processes? An export that returns only the order number and the total amount does not count as having kept the history.

The last question is the most critical: can redirect rules be written? If they cannot, on migration day you are left with no way of preserving the URL structure. We explained how that work is run, step by step, in our article on URL mapping during a store migration.

Decision table: from need to platform family

The table below does not recommend a brand; it shows which need points to which family. The rows are not mutually exclusive, and more than one can apply at the same time.

Once the table is filled in, the two or three options left are tested in a demo environment. The test should be run not through a sales call but with your own real product data: loading twenty real products with their variants and managing them in the panel tells you far more than an hour-long demo.

Two situations where postponing the decision is right

Not every business needs to choose a platform straight away. In two situations waiting is easier to defend.

If the product and pricing setup has not settled. In a business that has not decided what it will sell, with which variants and at what price, the platform gets chosen against an undefined need. In that case it works out cheaper to sell for a few months inside a small setup that is easy to leave, then decide with real data.

If the real bottleneck is demand itself. Building a site does not create demand. If your product has no visibility at all on the search and recommendation side, a bigger platform will not close that gap. In that situation the right order is to look first at where demand will come from, and then choose the platform that will carry that volume.

Which tasks sit with whom on the setup side, which decisions stay with the business and what we do not promise are all written down in the scope and limits section of our setup service. For visibility work on the sector side you can look at our ecommerce solutions page, and if you would like to draw up your own requirements list together, leave us a short note.

Frequently Asked Questions

We are starting with few products; if we grow, will we have to migrate?

Not necessarily, but the possibility is real. What decides it is less the number of products than how channel and variant complexity grow; a store that stays on one channel can run on the same setup for a long time. The way to make that possibility cheaper from the start is to ask about exit cost at the selection stage: if data can be exported in full and the URL structure can be changed, a migration is laborious but manageable. If those two conditions are not met, your options narrow at exactly the moment you grow.

On a hosted platform, are the changes needed for search and AI visibility possible?

In most cases the basic changes are possible: title and description fields, URL structure, the sitemap and structured data output can usually be managed. The limit varies from provider to provider, and that is exactly what needs to be asked in writing before you buy. There is a practical test: on the demo store, open the source of a product page and check whether the product data is there in machine-readable form and whether that output can be edited.

Is open source really free?

The software licence may be free; running it is not. Server, updates, backups, security and stepping in when something breaks are each a work item, and they consume either an in-house person's time or a service bought from outside. The right comparison is not "is there a licence fee" but "whose job is it to keep this setup running for twelve months, and what does that person's time cost". For businesses with a technical owner, open source is a strong option; for those without one, it often produces a hidden cost.

We sell on marketplaces; do we really need our own site?

It is not mandatory, but two things do not stay with you on a marketplace: the customer relationship itself, and a source about the brand that can be read on the open web. The marketplace channel brings sales; in return, the platform sets the rules of price competition and decides your access to customer data. Your own site is both a channel independent of those rules and the only version of your product and brand information under your own control. The decision is usually not "one or the other" but how much weight to give each.

Should the agency choose the platform, or should we?

The decision belongs to the business; the agency's job is to make the options comparable. In a healthy engagement the agency does not hand you a brand name; it draws up your requirements list, runs the same tests on two or three candidates and gives you in writing where each candidate reaches its limits. If an agency champions a single platform, it is fair to ask about its commercial relationship with that platform; that relationship is not always in bad faith, but it is information you should have when you decide.