4 mistakes in selecting an ecommerce engine
This year (2023), I’ve engaged in over 100 conversations with ecommerce directors and owners of online businesses. Several fascinating conclusions emerged from these discussions. One of them is that the same mistakes are made often in choosing an ecommerce engine (both for online stores and B2B ecommerce). I decided to list the most common ones because there’s no point in repeating them.
What are the most common mistakes in choosing an ecommerce engine?
My experience with ecommerce engines
The 4 most common mistakes in choosing an e-commerce engine
Summary
I will present 4 common mistakes that occur during the selection of an ecommerce engine. These mistakes often lead to the selection of a suboptimal ecommerce engine for a particular business.
If you are interested in delving deeper into this topic, I encourage you to continue reading.
In 2023, I spoke with about a hundred people serving as ecommerce directors or owners of large and medium-sized ecommerce enterprises.
I’m not talking about short conversations at conferences, but lengthy discussions during which I got to know the business situation of a given enterprise in detail. We often have talks with potential clients who come to us intending to collaborate.
The first meeting usually lasts about an hour, and then we often organize workshops that last several hours. This allows us to get to know the business situation of the organization quite well.
This year, I conducted over 100 such conversations, which allowed me to observe certain trends and patterns. Of course, don’t treat this data as quantitative.
On the other hand, 100 in-depth qualitative interviews already provide a good view of the market.
I find the conclusions from these conversations extremely interesting, and some of them are very non-obvious.
In this post, I will focus on the most common mistakes made when deciding on an ecommerce engine.
I noticed that the most common mistake, which came up in many conversations, is the decision to choose a specific ecommerce engine without knowing its future maintenance and development costs.
A perfect summary of this issue was the statement of one person who realized only after presenting the perspective of maintenance and development costs of a given engine for the next five years that they would need a budget amounting to several million euros.
There is something called the total cost of ownership.
In the case of ecommerce technology, we should always consider several elements. We should take into account:
All this together constitutes a sum that we can call the total cost of ownership. There is a significant difference between saying that the cost of implementing Magento will be about 98.000 EUR/USD and then maintenance will cost a few dozen hours monthly and hosting about 840 EUR/USD versus saying that over five years, the total ownership costs will amount to around 700.000 EUR/USD.
The indicated amount is, of course, made up, but it shows a completely new perspective. In practice, most decision-making does not take into account the total cost of ownership.
It doesn’t only apply to Magento but many other engines. Similar stories were heard about PrestaShop or Shopify, for example.
The maintenance cost of something like Shopify often seems to be just tens of dollars monthly. But in reality, there are additional costs for third-party modules, transaction fees, and minor graphic changes that constantly pop up. As a result, monthly costs can sometimes reach up to tens of thousands of euros.
Eventually, ecommerce directors often opt for technology that simply exceeds the available budget.
The second mistake is a decision to implement PWA solely to achieve high scores in Google PageSpeed. PWA is not an ecommerce engine. We should rather say that it is a type of front-end. Nevertheless, I decided to include this mistake on the list.
If your only goal is to achieve high scores in Google PageSpeed, then choosing PWA is a mistake.
It is difficult to find headless implementations on the market that are exceptionally fast. The story usually looks like this: someone switched from Luma to PWA (within Magento) to increase speed. The results on Luma were around 40 on mobile and about 70 on desktop. Unfortunately, after implementing PWA Studio, the mobile version dropped to 7 points, and the desktop version to 50. It’s not easy to create a fast ecommerce site on PWA.
Add to this that the cost of implementing PWA is high.
In any case, choosing PWA just to have high scores in Google PageSpeed is shooting a cannon at sparrows. There are plenty of other and less expensive actions to improve these scores.
The first thing that comes to my mind, for example, is the implementation of server-side GTM. Generally, traditionally implemented GTM reduces the mobile scores by 20 – 30 points.
Let’s consider what is easier and faster: implementing a new front-end for 1500 hours or working within the scope of GTM implementation?
The latter is the faster solution.
We decide on PWA if the business model justifies its implementation. For example, if we are a store whose hosting costs amount to tens or hundreds of thousands of euros, then in this case, separating the front-end from the back-end will bring us significant savings (we will not need expensive hosting to maintain the backend).
If improving Google Page speed is the only reason we want to implement PWA, we should abandon this idea. There are most likely simpler, faster, and cheaper ways to achieve this effect.
Another common mistake when choosing an ecommerce engine is selecting a platform that does not operate optimally when there is a significant departure from the standard.
Every platform has its standard operating mode and standard functionalities available out of the box. Any ecommerce technology will work efficiently at the level of these basic functions.
The problem arises when our business is so specific that we significantly modify the ecommerce engine and deviate from the standard way it operates.
Some ecommerce engines handle this departure from the standard well and operate efficiently, while others generate errors.
For example, the SaaS IdoSell works great out of the box, but it can be difficult if we want to deviate from its standard significantly.
Shopify handles this better, but it’s not perfect either. A significant advantage of Shopify is the marketplace with add-ons we can purchase. They are carefully verified, but Shopify with 40 installed third-party modules no longer operates as swiftly.
If we choose Open-Source, Presta works great out of the box, but after adding additional functionalities that deviate from the standard, it starts to falter.
It’s quite different in the case of Sylius or Magento. These engines are designed in such a way that they work correctly both out of the box” and after adding more functionalities, even if they significantly deviate from the standard.
In such a case, if we know that we have very specific functionalities and the standard ecommerce engine does not meet these requirements, we should not decide to build an ecommerce solution based on platforms that start to have problems when we depart from standards.
Choose solutions that work efficiently, even when deviating from the standard.
The last common mistake made when choosing an ecommerce engine is deciding on a dedicated solution.
I know that’s a controversial statement, but it’s not just my opinion. It’s simply confirmed by the conversations I’ve had. This year I met only one ecommerce director who was happy with the dedicated solution for their business.
The most common problem is implementing any changes. Supposedly, a dedicated solution is chosen precisely so it can be perfectly tailored to our requirements. Meanwhile, any changes are tiresome, lengthy, and expensive. For example, adding a new courier.
In a standard ecommerce engine, there is probably a module, whose installation and configuration will take 8 hours. In the case of a dedicated system, of course, you have to write it from scratch—you have to dedicate 180 hours to add a new courier. That seems absurd.
There are also concerns about the stability of the technology partner. If the company had more employees before and now has fewer, questions may arise as to whether it will continue to develop its business. If the technology partner decides to end this business, we are left high and dry.
In such a case, a quick transition to another ecommerce engine that’s supported by at least several large ecommerce agencies may be necessary. It will ensure maintenance and developmental support for that ecommerce engine.
Dedicated solutions had their time of glory when SaaS solutions were more closed and had limited functionality. Open-source engines were not yet so developed and did not have such a large community around them.
In this article, I described the most common mistakes when choosing an ecommerce engine that I deduced based on several hundred conversations with directors and owners of online stores.
The 4 most common mistakes are:
If you are currently in the process of selecting an ecommerce engine and are wondering what would work for your business, I have written a good article on whether to choose SaaS, a dedicated solution, or maybe Open-source. I think the process I use for matching an engine will surprise you.
