The decision about which e-commerce platform to choose almost always lands in the same place: on the desk of the IT department or of an external technology vendor. The question "what should we build the store on" sounds technical, so it is naturally delegated to technical people. This is one of the most expensive categorisation errors we see in the mid-market.
"Which platform" is a derivative question. It follows from the kind of business you are building for the next five years: B2B or D2C, one market or expansion, a catalogue of two thousand or sixty thousand SKUs, a marketing team or a technical one. IT answers that question differently than the business would — and it does so systematically, not by accident. Below we show why this happens, three anonymised cases in which IT decided on behalf of the business, and a simple framework that puts this decision in the right order.
Why this decision ends up with IT in the first place
Choosing a platform looks like an engineering problem. You have to compare stacks, APIs, performance, hosting models. A management team that does not feel confident in those areas is happy to hand the decision to people who do. The problem is that it hands over the weightings as well — and it is the weightings, not the list of criteria itself, that decide the outcome.
The most expensive investment in e-commerce is a store that has to be rewritten after a year because the chosen architecture could not withstand the growth of the business. A platform is chosen for the 5–7 years of the product's life, not for the next launch. And the horizon on which this decision is best assessed — the revenue model, the roadmap, the fit with the team — is by definition a business one, not a technical one.
What IT optimises for (and why that is not the same as the business)
A good IT department does not choose badly out of bad faith. It chooses what an IT department values — and it values things that are real and sensible from its own perspective:
Control and flexibility. Full access to the code, no SaaS limitations, the ability to build anything. Open source on your own server beats a closed ecosystem.
No vendor lock-in and no licence fees. A licence of USD 2,200 a month plus a percentage of turnover looks like waste to an engineer, when "the same thing" can be built on a free engine.
A familiar stack. A team that has worked in WordPress or Symfony for years naturally gravitates towards what it already knows how to maintain.
Technical elegance. Headless, clean architecture, a modern front end — things that look good in code review.
Each of these values is justified. None of them is identical with what actually determines revenue: time to market, the cost of ownership over a three-year horizon, and who really runs the store day to day.
In our platform comparison we assess every engine across six dimensions: the admin panel, configuration, room for development, performance, SEO and security. IT instinctively attaches the greatest weight to "room for development", because that is its world. The business should weight "the admin panel" most heavily, because that is what decides whether marketing launches a campaign on its own or files a ticket with a developer for every change. That single shifted weight is enough to produce a different result.
Three cases in which IT decided on behalf of the business
The stories below are composite, anonymised archetypes, not specific clients — and the turnover figures are illustrative. Each of them is, however, a pattern that recurs regularly in the mid-market.
Case 1: over-engineering for a simple D2C business
A natural cosmetics manufacturer, around PLN 12 million in annual turnover, D2C sales, a simple catalogue of up to two thousand SKUs, plans to expand into the DACH markets. IT recommends a custom build on Symfony/Sylius: "full control, zero lock-in, we will build exactly what we want".
The reality of the business was different. This is a marketing brand, not a technology one — with no in-house PHP team, but with the ambition of entering Germany and Austria quickly. Sylius can do everything, but customisation takes time: an implementation on that engine typically takes 16–22 weeks, while Shopify Plus delivers a production-ready store in 8–14. The Sylius panel is designed for developers; the Shopify panel — for marketers. The result: every campaign and every change on the site required a developer, and multi-currency and multi-language, which come ready in Shopify Plus, had to be built on top. The brand lost the seasons in which it should already have been selling in DACH.
IT optimised for control. The business needed time to market and marketing independence.
Case 2: the SaaS ceiling under the weight of B2B
A distributor of industrial parts, around PLN 40 million in turnover, more than sixty thousand SKUs, individual price lists per customer, trade credit, a catalogue driven from the ERP. This time IT chose the opposite way: Shopify Plus, "because it is SaaS, we do not have to maintain infrastructure and we will go live quickly".
Shopify Plus is excellent for D2C, but B2B is not its strong suit. Individual price lists, credit limits and contract logic require apps and custom work there — things that Sylius has natively. On top of that, a catalogue above fifty thousand SKUs rubs against the limits of SaaS comfort. Every B2B rule became another paid app, and the bill added up: USD 2,200 a month for the licence, plus an app stack (typically USD 200–800 for the mid-market) and transaction fees. The real cost of running a store with turnover of around PLN 20 million can reach PLN 15,000–25,000 a month — and a model that was supposed to be "cheaper, because there are no servers" turned out to be more expensive and brittle at its core.
IT optimised for its own operational simplicity. The business was fundamentally B2B and needed a platform that treats price lists and trade credit as the standard, not as an exception.
Case 3: a familiar stack instead of a roadmap
A furniture manufacturer, around PLN 15 million in annual turnover, a growing catalogue with product configuration (dimensions, fabrics, variants), plans to enter marketplaces. IT proposes WooCommerce on WordPress: "we know WordPress, we have it on other projects, there is a plugin for everything".
At the start it worked. The problem appeared as the business grew. WooCommerce is the cheapest way in, but you pay for its flexibility with maintenance — performance and security are its weakest dimensions, and every new need means another plugin and another surface for failure. As the catalogue and the traffic grew, the store slowed down and the list of plugins to look after swelled. After a little over a year, the business had grown into exactly the most expensive option: rewriting the platform — because the chosen engine matched the comfort zone of the IT team rather than the roadmap for the coming years.
IT optimised for familiarity with a tool. The business needed a platform matched to where it will be in three years, not to what the team already knows.
A platform is not a technology choice with business consequences. It is a business choice with technology consequences. The order is not cosmetic — it determines the outcome.
What this decision should look like
The rule is simple: criteria and their weights first, platform names second. Both the business and IT at one table — but with a clear division of roles. Before anyone utters the word "Shopify" or "Sylius", answer seven questions:
Business model. B2B, D2C or hybrid? This decides price lists, trade credit and checkout — and most often narrows the list down to two platforms on its own.
The 3–5 year roadmap. Geographic expansion? New channels and marketplaces? How many SKUs will the catalogue grow to? A platform is matched to the target state, not the starting one.
TCO, not the implementation price. Licence plus apps plus maintenance plus the cost (and availability) of developers over a three-year horizon. A free engine is sometimes the most expensive.
Time to market. How much time the business realistically has to launch and start iterating.
Who runs the store day to day. Marketing or the technical team? That decides whether the panel has to be for marketers or can be for developers.
Availability of skills. Will we be able to maintain this stack? Symfony developers are in short supply in Poland — a great platform with no people to run it is a risk, not an asset.
Resilience to change. How much does the choice tie our hands when the business turns sideways.
IT's role in this process is indispensable — but it is the role of an expert, not of the decision-maker. IT assesses the shortlisted platforms for feasibility, integrations, performance and security, and raises red flags. The business sets the weights of the criteria and picks the winner. When IT is given the right to set the weights, the decision imperceptibly shifts towards what IT values — and comes back to the company in the form of the three stories above.
Matching the platform to the business profile
There is no "best platform" — there is the platform best matched to a specific profile. This is the mapping we use most often (you will find the full, six-dimensional comparison of nine engines in our platform rankings):
Business profileWhat we usually recommendWhyD2C, simple catalogue, EU expansion, marketing teamShopify PlusTime to market in 8–14 weeks, multi-currency and multi-language ready, a panel for marketersB2B, individual price lists, trade credit, ERP, 10–100k SKUSyliusB2B logic and custom work natively, full control over the code, headless modeMid-market in PL/EU, moderate budgetPrestaShopPopular in Poland, good for the mid-market, lower cost than enterprise SaaSSmall/medium store, minimal starting budgetWooCommerceThe cheapest way in — but you have to reckon with the cost of maintenance and plugins
Two of our projects show how this works when the fit is right: Shopify Plus for the D2C brand Topeshop, where the migration from PrestaShop lifted conversion by 58% — and Sylius for B2B, such as the product configurator at KMK Klinkier. In both cases the platform was decided by the business profile, not by a stack preference.
Summary
Choosing an e-commerce platform is a business decision with technical consequences — not the other way round. IT is indispensable in it as the voice of feasibility and risk, but when it is given the right to set the weights, it systematically optimises for control, a familiar stack and elegance instead of time to market, TCO and fit with the team. Set the criteria before the platform names, seat the business and IT at one table with a clear division of roles — and you will avoid the most expensive scenario, namely rewriting the store after eighteen months.
If the platform decision is ahead of you, a good first step is an independent audit and platform consultation — it ends with a document containing a recommendation for the board, based on the profile of your business and not on the preference of one of the parties. We will gladly go through it together with you; write to us via our contact page.