Differences in Magento Implementation: 40.000 USD/EUR vs 90.000 USD/EUR
If you want to find out where such big differences in price come from, even though they are offers received on the same request for proposal, read this article!
What are the differences in Magento implementation for 40.000 USD/EUR vs. 90.000 USD/EUR?
Comparison of hourly rates and number of hours
What are the differences in Magento implementation?
What results from the discussed differences?
Summary
To start with, a simple answer to this complex question. The difference mainly results from the different scope of work within both implementations.
There are several key differences, such as:
This is a brief answer to this question; however, if you’re interested in this topic, I encourage you to read the main part of this article.
I recently spoke with one of our clients who was collecting offers for a Magento store implementation and reached out to four companies.
All the companies responding to the same proposal request prepared completely different offers. Two offered Magento implementation for a budget of around 40.000 USD/EUR, while the remaining two offered around 90.000 USD/EUR.
The client naturally wondered where such a big difference between the offers came from since all the ecommerce agencies assured that they included all the functional requirements from the brief, which were further specified during additional meetings.
First, I suggested to the client to compare hourly rates primarily. It turned out that all ecommerce agencies proposed an hourly rate within the range of 65 USD/EUR – 70 USD/EUR.
Since the hourly rate was almost identical, and all the agencies prepared the offer for implementation in a time and materials model, the difference had to be in the number of hours dedicated to the project.
In the case of two agencies, the number of hours was more than twice as small as the remaining two. This meant that the ecommerce agency assessed the labor intensity of implementing the identical online store at practically half as much, which is quite interesting.
Then the question arises about where this difference in the number of hours comes from.
It may be related to the project team. If the project team has a lot of inexperienced people, such as juniors, they will need more time to code a given functionality.
Thus, if the ecommerce agency proposed the same hourly rate, but one team consisted of mid-level and senior developers and the other of juniors and mids, it is clear that the one with the less experienced team would need more hours to code the given online store.
However, the search for problems in this area failed because all four ecommerce agencies proposed a very experienced team consisting exclusively of seniors and mids.
We have a situation: the hourly rate is the same, the team is very similar and certified by Adobe in Magento, and the only differentiating factor between the offers is the number of hours.
One agency wants to implement a specific Magento project for over twice fewer hours, while the other for a significantly larger number of hours.
In such a case, these implementations are different – they must differ since different hours are dedicated to their realization.
I will present the most common differences between offers, which greatly affect the number of hours.
Suppose you receive an offer for Magento, and it turns out that two agencies present you with an offer for 190.000 USD/EUR and another two for 75.000 USD/EUR. In that case, you can conduct the same analysis of the offers and probably quickly find the “details” that differentiate the scopes.
I often see offers where pre-implementation analysis takes 10 or 20 hours, for example. There are also offers where this pre-implementation analysis takes much more time and costs 10.000 USD/EUR, 15.000 USD/EUR, or 17.500 USD/EUR.
This is a huge difference. Therefore, the scope of this pre-implementation analysis for 15.000 USD/EUR cannot be the same as the one where the pre-implementation analysis takes 20 hours.
In 20 hours, conducting a sensible number of workshops is impossible. When a business analyst and ecommerce consultant conducts a workshop, one such meeting can take 3 hours, giving us 6 hours of work.
In such a case, one workshop constitutes 1/3 of the time for pre-implementation analysis. It is clear that if the pre-implementation analysis is to last 20 hours, it is not a full analysis but more of a superficial summary of the scope and perhaps just a copy-pasting of arrangements from the offer.
The difference in pre-implementation analysis can be significant, often reaching tens of thousands of euros.
If your offer includes the performance of pre-implementation analysis, which is to last a few, a dozen, or 20 hours, then most likely it is not a full pre-implementation analysis.
It certainly does not include workshops or the preparation of graphic designs or system architecture. Simply, it is not possible to do this in such a short time.
You might get a Word document copied from other projects that generally describes the implementation scope. The description is so general that later, it may turn out that your perception of how a certain functionality works will be completely different from reality because the function description in the document does not describe the intended final effect.
Good pre-implementation analysis gives you financial security. If you conduct an extensive pre-implementation analysis, which accurately describes the project scope, the likelihood that the budget estimated based on such analysis will be consistent with the final cost of implementing your ecommerce is much greater.
If the analysis is superficial, there is a risk that the budget for the online store implementation will significantly increase. We are not talking about an increase of several tens of percent but by several times.
Another important aspect is the type of integrations implemented. There is a significant difference in the cost of implementing an API integration and exchanging CSV files.
A faster and safer integration, subject to fewer errors, which allows automation of all orders and does not generate errors, uses an API.
However, sending CSV files is often full of errors, slow, and does not provide immediate data exchange. This poses a major problem, especially in businesses where goods rotate quickly and come off the stock or prices change dynamically.
Implementing the first type of integration often costs 160 hours, and performing the second just a few hours. This affects the cost of the integration and the final effect. An integration with an API is different from one using CSV files.
Another aspect that often differentiates Magento projects is the PIM implementation.
In the case of larger Magento implementation quotes, the agency often implements PIM right away, such as Akeneo or Ergonode. In smaller projects, PIM is usually not included, and the management of cold product data is supposed to be done through the ecommerce system.
If you operate in several markets, support different languages, and sell through various channels, not only in ecommerce but also on various marketplaces or offline, implementing PIM becomes almost mandatory.
There are two reasons: firstly, the number of errors will decrease, and there will be no need to standardize data for different markets manually. Secondly, PIM facilitates the implementation of AI automation, which, with such a large amount of created content, is a huge time saver.
Often, in implementations that cost significantly less, an attempt is made to implement most functionalities by installing third-party modules.
However, this is not an ideal solution. I have already written about using third-party modules on the blog, so I encourage you to read it. I also wrote about technical debt, which I recommend to those interested in ecommerce projects.
After reading these two posts, you will understand what it means to use many third-party modules.
In short, using many third-party modules generates very high costs for later maintenance and development of the site, which is problematic. This leads to a situation where you save, say, 39.000 USD/EUR on the implementation, but maintenance will cost many times more due to this saving.
Another aspect differentiating Magento implementations is whether a given functionality meets your needs.
For example, consider the functionality of a wishlist in your ecommerce store. If functionality is not precisely described, it is unknown whether the wishlist will work only for logged-in users or those who are not logged in.
Suppose the ecommerce agency thoroughly discussed this issue before preparing the final offer and found out how you want this wishlist to function. In that case, the implementation of such functionality may turn out to be more expensive.
For example, if the wishlist is to work also for non-logged users, the implementation cost will be higher than if it were to work only for logged users.
The price difference can be several hours of work on a single functionality, which leads to a significant cost difference in the case of a larger number of functionalities.
Suppose the pre-implementation analysis describes the functional scope only very generally. In that case, you may face the problem of receiving functionality that does not meet your expectations during the implementation. The name of the functionality agrees, but that’s it. In reality, it does not work according to your expectations.
Ecommerce agency may then state that the missing elements can be added, but this will involve additional costs, as they were not included in the original estimate. The implementation was supposed to cost 39.000 USD/EUR, but the budget gradually increased.
The offer must include a budget for UAT (User Acceptance Testing) and for fixing any errors after these tests, as well as a budget for the production launch.
The definition of the end of the Magento implementation may differ – it may be the moment of launching the service for final users or when all functionalities have been coded. Still, the service is not yet available for final users.
Often, ecommerce agency offers do not include conducting UATs, fixes after these tests, and the production launch. If these elements are not included, you will have to cover these additional costs not foreseen at the offering stage.
It turns out that in the offer for, for example, 90.000 USD/EUR, this scope of work is included in the price, but in offers for 40.000 USD/EUR, it is not.
It is also important to include tests (quality assurance). These are testing processes that ensure that the coded elements are free from errors and are done according to acceptance criteria.
Before being handed over to you, a tester should check each functionality.
I often notice that offers for Magento implementation provide only a few hours for these manual tests as part of the project. It is not possible to test each functionality within a total of a few hours.
Consequently, the work of a manual tester is done not by the ecommerce agency but by you.
This means that although you will pay less for ecommerce implementation, you will lose more time on testing and communication with the ecommerce agency regarding the correction of individual elements of the service.
Another important aspect I would like to highlight is that Magento implementations differ depending on the agency’s approach to the graphic project.
Whether the created frontend is an individual graphic design, a slightly modified third-party template already exists, or whether a third-party template is used, such as Luma.
You can slightly modify a template, which will take about 80 hours, or create and code an individual store with a unique graphic design, which may take over 800 hours.
Which approach is right? If you want to increase the conversion rate and stand out in the market, using a template created to work in all industries with all types of users and products is not enough. It is a typical all-in-one solution and, thus, often does not generate a high conversion rate.
There are specific UX rules according to which the front end should be created, but optimizing and preparing a graphic design perfectly adapted to a specific industry, products, and how the user purchases them translates into a higher conversion rate.
If you spend hundreds of thousands of USD/EUR on an online store, do you want to base it on a third-party template or an individual graphic design? If you use a template instead of Magento, you should choose a SaaS solution, such as Shopify, which, in this case, will be a much better solution. The implementation will cost less, and its maintenance as well.
If we sum up all the differences, it will quickly turn out that they can easily cost even 50.000 USD/EUR. This means, in short, that, of course, it is possible to create a store on Magento 2 for a much lower budget, but expecting it to deliver the same value as Magento 2 implemented in twice as many hours is simply wrong.
In practice, for 40.000 USD/EUR, you get a low-quality product for Magento 2 projects. In this budget, a better choice would be Shopify, offering a significantly better graphic design and more features for the same price.
If you want to create a great online store or B2B ecommerce on Magento, with API integrations and an individual graphic design, without a large technical debt and which will be transferable – it is not possible to implement it on a budget of several hundred thousand EUR/USD.
Even if you buy a boxed Magento solution, in this budget, there is no room for integrations via API, only one courier is assumed, and there is only one ready-made graphic template available, which is used in many other ecommerce projects, so you will not stand out in the market.
In my opinion, this is not the best way to build a competitive advantage, but business decisions in your ecommerce are up to you.
I would pay attention to understanding where these budget differences come from. They do not result from the agency working twice as slowly. With developers at the same experience level, the times will be similar.
However, the scope of implementation and how the project is executed differ in each case, and that’s where these differences come from. In your specific case, one or the other solution may be better, but if you think both implementations are identical and will provide you with the same value, this is not true.
The differences in Magento implementation for 40.000 USD/EUR vs 90.000 USD/EUR result from the fact that the project scope is different. If you start specifying this scope and the way of executing individual elements, it will turn out that they are performed in various ways.
A few examples that show how this scope may differ, for instance:
If you are deciding on a Magento solution and are wondering if the offers you received are comparable, contact me on LinkedIn or send a form to our website. We will analyze your situation, examine your expectations, and propose a concept that, in our opinion, will work best in your business.
