A conversation about a new store almost always starts the same way. The client has three pricing pages open in three tabs and asks which platform is cheaper. Except the real question is something else entirely – whether their way of selling can be reproduced in that tool without holding everything together with tape and manual exports to a spreadsheet.
The price list grabs attention because it is the only thing visible before launch. The rest surfaces later: at the first accounting integration, during the first sale season, at the first return that cannot be settled according to company procedure.
That is why we treat choosing an e-commerce platform as a decision about processes, not about a subscription. Orders, warehousing, settlement, complaint handling – these set the limits of what can sensibly be built. A B2C store with a single warehouse and a wholesaler with individual pricing for every business partner ask the identical question, and they should hear two different answers.
Table of contents
Start with a map of processes, not a list of features
The question “does the platform have feature X” leads nowhere. Every one of them will say yes, only at a different level of detail. It is better to describe the path of an order from click to invoice and possible return, marking every point where a person or another system steps in.
In our experience, a few areas decide the choice:
- Pricing model and discounts – prices visible after login, quantity thresholds, individual commercial terms.
- Variants and configurators – products assembled from options, pricing that depends on parameters.
- Stock levels and reservations – multiple warehouses, holding goods for the duration of payment, backorders.
- Sales documents and tax compliance – invoices, corrections, rates for different countries.
- Logistics and returns – courier labels, pickup points, the complaint workflow.
- Multiple markets and languages – separate catalogs, currencies, content.
- Team permissions – who sees margins, who can change a price.
The most common mistake? A decision made during a demo. Everything looks similar there, because every solution can put a product into a cart. The real warning sign is different: if a process today lives in a spreadsheet and an email inbox, no platform will fix it on its own. First it has to be written down.
Where configuration ends and code begins
Each of the three solutions draws that line somewhere else. Shopify closes off the backend and pushes unusual logic into apps and functions running in the vendor’s cloud, which is why we plan store implementations on the Shopify platform differently from the rest. WooCommerce and PrestaShop hand over access to the server layer, so changing how the store behaves is often a matter of a single hook in the code.
The consequence is architectural, not cosmetic. In a closed model you pay with flexibility: some things simply cannot be done, and workarounds have to fit inside someone else’s limits. In an open one you pay with responsibility: for updates, for security, for the cart still working after a patch goes live.
Take non-standard prices for a logged-in business partner. In one world that is a plugin and a few lines in the code that calculates the price. In the other, a dedicated app, more API calls and the question of whether it will answer before the page renders. But note: the closed model can be a genuine advantage for a small team without an IT department that does not want to wake up to a broken store after a nightly update.
Integrations decide more often than the store itself
A store rarely stands alone. Next to it work an ERP, a warehouse, an invoicing system, payment gateways, couriers, sometimes a CRM and marketing tools. And it is those connections, not the graphic template, that generate most of the risk in a project.
The question we ask before the choice sounds like this: should the data exchange be synchronous or queued, and what happens when the other side goes silent. “We will try again” is not enough if in the meantime a customer bought goods that are no longer there.
API limits and webhook restrictions in cloud platforms can overturn a bulk stock synchronization that nobody counted at the quotation stage. A catalog updated every fifteen minutes from a warehouse system looks harmless. Until it collides with a hard request budget. On the open side we most often come across online stores built on PrestaShop wired to an ERP, where queuing can be set up your own way.
The second classic is an off-the-shelf ERP connector bought without checking whether it maps every field used by accounting. It usually ends with a middle layer that has to be written anyway. Only later and under pressure.
Cost structure: what really drives the bill
The bill for a store consists of a license or subscription, transaction fees, plugins and apps, hosting, implementation, integrations and ongoing maintenance. The price list shows the first of these components and stays silent about the rest. So that a budget conversation has something to hold on to, we publish indicative pricing for implementations.
The cloud model spreads the cost over time and ties it to turnover: the more you sell, the more you pay, but you do not worry about the server. Self-hosted shifts the expense to the start and to the team that then updates, tests and watches over security.
Open platforms carry a hidden cost in dependencies. Every plugin is someone else’s code that may stop being developed and block updates to the whole store, security patches included. Closed ones have their own: working around a missing feature can be more expensive than writing it outright, because it has to be squeezed into limits you do not control.
Scaling, security and data, or life after launch
Scaling in online retail rarely concerns traffic on the site. Almost always it is about the database. A catalog with a large number of variants, a growing order history, queries filtering by attributes – that can slow down a store that ran flawlessly at launch.
Responsibility for security is split completely differently in the two models. In the cloud the vendor updates and it is their problem. In the self-installed version it is done by a specific person on the team or, which we see most often, by nobody. Until an incident.
Customer and order data is an asset, not a side effect. It has to be exportable in raw form, otherwise analytics rests on the vendor’s charts and a future migration turns into an archaeological project. Maintenance is planned before launch: who updates, where the backup sits, what the test environment looks like and how a change is rolled out.
What a good decision looks like in practice
A good decision is reversible. It assumes that in two years the conditions may change, so integrations are designed with replacement in mind, and data is kept in a way that lets it be moved without rewriting half the company.
The profiles line up fairly clearly. A simple catalog and a fast start – the cloud model. A store tightly fused with content and an existing WordPress naturally leans toward a solution such as a store built on WooCommerce. Extensive sales with custom business logic and many markets require full control over the code.
Before signing a contract I recommend a simple test: describe the three hardest scenarios in your process and ask the vendor to show how they will handle them in the proposed solution. A successful rollout starts with the process and ends with the platform. An unsuccessful one goes exactly the other way around.
Summary
A platform is a tool for handling a sales process, so there is only one order: first describe the process, then compare the tools. The price list starts to make sense at that point, because you finally know what exactly you are buying.
Take three check questions away from your meeting with a vendor. Where configuration ends and programming begins. How the integrations will behave under load and when the other side fails. Who maintains this store a year from now. The answers will tell you more about the project than a feature list.
At Web Systems we have been designing web applications, B2B systems and integrations since 2006, so we look at a store as part of a larger puzzle. If you are choosing a platform, planning to connect sales with an ERP, a migration, process automation or a modernization of a working store, get in touch – we will start with your process, not with a ready-made recommendation.
