When planning the implementation or further development of an e-commerce platform, many companies send a request for proposal to several software houses. A few days later, they receive responses that are often… dramatically different.
One proposal comes in at PLN 300,000, another at PLN 650,000, while a third exceeds PLN 1 million.
Where do such significant differences come from if all three companies are estimating the same project?
In practice, very often… they are not estimating the same thing.
Although all the proposals concern the same e-commerce platform, they may cover completely different scopes of responsibility, levels of analysis, approaches to architecture design or ways of managing risk. The differences are not solely the result of the number of developer hours. Much more often, they are a consequence of decisions made before development even begins.
That is why comparing only the final price can lead to poor business decisions.
In this article, we explain how to evaluate software house proposals, which elements have the greatest impact on project estimates and what questions you should ask before choosing a technology partner.
This is one of the most frequently asked questions when choosing a technology partner. At first glance, the project looks identical. The same e-commerce platform, the same requirements, the same delivery deadline. Yet the estimates can differ by hundreds of thousands of zlotys.
Most often, this is not simply because one company "charges more" and another "charges less". The difference lies in what each company considers part of the project. In theory, both proposals concern the same implementation. In practice, they describe two completely different scopes of responsibility.
Two proposals may concern the same project while covering completely different scopes of work. Before comparing prices, it is therefore worth checking what is actually included in each estimate.
Below are the areas that most often account for differences between proposals.
Not every software house starts a project with an analysis, although in our view, skipping it is a serious mistake. Some companies assume that the documentation provided by the client is complete and prepare their estimate on that basis. Others begin the engagement with Discovery workshops (that's us!), during which they verify business processes, architecture, integrations and the scope of the first implementation phase. Both approaches can lead to project delivery, but they involve different levels of risk.
If the analysis is not completed at the beginning, some decisions will have to be made during development. This often means additional scope changes, a longer timeline and higher costs.
Question to ask the software house: Was the estimate prepared on the basis of a complete project analysis or only preliminary assumptions?
Read also: how to run a professional Discovery workshop for B2B e-commerce implementations.
At Commerce Weavers, we do not start by recommending a technology or presenting a ready-made estimate. First, we want to understand the client's individual situation: their business model, processes, goals, constraints and current technology environment. That is why, before making key decisions, we talk to the team, analyze the available materials and, depending on the project, conduct a Discovery or an audit. Without this, we could base our recommendations on assumptions that later turn out to be incorrect. And then even a technically sound decision may be the wrong one for that particular business. A good recommendation should result from a diagnosis, not precede it.
The proposal should clearly state whether system architecture design is included and what the scope of this stage is.
This is not only about choosing the technology. Architecture also covers the division of responsibilities between the e-commerce platform and external systems, the approach to integrations, data flows, key dependencies between components and preparing the solution for further development.
It is worth checking whether the project will define, among other things:
the responsibilities of individual systems,
the approach to data exchange and integrations,
key scalability and security decisions,
the approach to developing future functionality,
principles for documenting the most important architectural decisions,
the person or role responsible for making and maintaining architectural decisions.
If this stage is omitted or reduced to ad hoc decisions made during implementation, many decisions will be made reactively. This increases the risk of scope changes, unnecessary dependencies and higher costs of future modifications.
What matters, therefore, is not only whether "architecture" appears in the proposal, but also whether it is treated as a separate area of responsibility. Key architectural assumptions should be defined at a high level as early as possible, but not treated as something fixed once and for all. Good architecture remains open to changes resulting both from pre-implementation analysis and from the implementation process itself.
Integrations are among the most complex elements of e-commerce projects, and their scope can vary significantly between proposals.
"ERP integration" is only one possible scenario. An e-commerce platform may also exchange data with PIM, CRM, WMS and OMS systems, payment systems, logistics providers, marketplaces, marketing automation tools, loyalty systems, BI, tax platforms or solutions used by business partners.
Each of these integrations can involve a completely different level of complexity. One estimate may cover only basic data exchange, while another may also include process analysis, mapping, queuing mechanisms, error handling, monitoring, retries and integration testing.
It is worth checking which systems have been included in the estimate, what scope each integration covers and who is responsible for preparing and maintaining the interfaces. However, it is difficult to expect a proposal to answer every detailed question at this stage, for example regarding error handling, monitoring or failure scenarios. What matters more is whether the proposal demonstrates a high-level understanding of these issues and asks the right questions. Specific solutions, particularly implementation details, usually emerge only during a workshop, audit or analysis.
Question to ask the software house: Have all integrations been estimated in detail, including the scope of data, responsibilities of each party, error handling and dependencies on external providers, or are some of them only assumptions used for the estimate?
Not every e-commerce project estimate includes the same scope of testing. It is worth checking whether the proposal includes, among other things:
automated testing,
manual testing,
integration testing,
performance testing,
security testing,
support during business acceptance testing.
The absence of some of these elements does not necessarily mean there is a problem. The scope of testing should reflect the architecture, the nature of the project and the level of risk. What matters is that it is defined consciously, rather than resulting from an imprecise estimate or an attempt to reduce the value of the proposal. It is also worth looking at what a quality and performance audit of an existing platform involves. It provides a useful reference point for what to expect at the estimation stage.
Testing is not an add-on to development or a cost worth cutting when looking for savings in a project. It is an investment in the quality and stability of the platform that pays off throughout the subsequent stages of its development. Well-designed tests make it possible to identify potential problems earlier, introduce changes more safely and respond faster when something starts working differently than it should. In many cases, they can even prevent a problem before the customer or the business experiences it. For a B2B or B2C e-commerce platform developed over many years, this investment can pay for itself many times over, because every subsequent change can be implemented with greater confidence and lower risk.
Question to ask the software house: What types of testing are included in the project, and who is responsible for preparing them?
Implementing an e-commerce platform does not end with writing the code. The project also requires preparing environments, the deployment process, monitoring and the rules for maintaining the system after production launch.
The proposal should clearly state whether it includes, among other things:
development and testing environments,
the production environment,
CI/CD configuration,
monitoring, logging and alerts,
backups and a data recovery procedure,
the ability to safely roll back a deployment,
basic security mechanisms,
responsibility for infrastructure maintenance after go-live.
A well-designed DevOps process affects not only the stability of the platform, but also the pace of its further development. The more repeatable and automated the process is, the easier it becomes to introduce subsequent changes without increasing the risk to the production environment.
It is also worth checking whether monitoring can only detect that the platform has stopped working, or whether it also makes it possible to quickly diagnose the source of the problem. In more complex projects, infrastructure metrics alone are not enough. Application logs, alerts and the ability to trace errors across individual system components are also important.
This is one of the areas where additional costs often appear after the contract has already been signed, particularly when the software house proposal does not clearly specify who is responsible for hosting, monitoring, backups, security and environment maintenance after the platform goes live.
Question to ask the software house: Are infrastructure setup, the deployment process, monitoring and environment maintenance after go-live included in the project?
Data migration is one of the most underestimated parts of e-commerce projects.
Moving products or customer records is usually just the beginning. In practice, you also need to assess the quality of the source data, determine how it will be mapped to the new data model and decide which information actually needs to be transferred.
A proposal should clearly specify:
which data will be migrated,
who is responsible for preparing and cleaning the data,
whether data mapping between the old and new systems is included,
whether the migration covers order history, customer accounts, prices, discounts or other business data,
whether the migration will take place in a single operation or in stages,
whether a trial migration is planned before the production launch,
who is responsible for validating and approving the data after migration.
It is also worth remembering that the biggest challenge is often the quality of the source data rather than the migration itself. Duplicate entries, incomplete records, inconsistent formats or data maintained according to different rules over the years can significantly increase the amount of work required.
A good proposal should therefore cover data preparation, testing and post-migration verification, as well as the technical transfer itself.
If these activities are not clearly defined, additional work may become necessary towards the end of the project, when there is the least room for changes to the schedule or budget.
Question to ask the software house: Has the data migration process been clearly defined, with specific responsibilities assigned, or is it simply mentioned as part of the implementation?
The same price in two proposals can represent completely different levels of commitment from the software house.
Start by checking which pricing model the estimate is based on: Fixed Price, Time & Materials or a hybrid approach. The model itself does not determine the quality of a proposal. What matters is understanding who bears the risk of scope changes and how those changes will affect the final budget.
A proposal should clearly specify:
whether the quoted amount is a fixed price or an estimate,
what rates or calculation methods apply to additional work,
which assumptions were made when preparing the estimate,
what will be considered a change in scope,
how additional work is approved,
whether a contingency budget has been included,
how frequently the client receives updates on budget utilization.
With Time & Materials, transparency around budget utilization is particularly important. With Fixed Price, a precisely defined scope and clear assumptions are equally essential, as changes to requirements may result in change requests.
Question to ask the software house: Is the quoted amount a binding commitment, an estimate or a budget based on specific assumptions? And what happens to the price if those assumptions change?
We've explored this topic in more detail in our article on what determines the cost of a Sylius implementation. Although it uses Sylius as an example, most of the principles apply to estimating projects built with any technology.
The total number of estimated development hours tells you very little about the team that will actually deliver the project. You should look beyond the overall effort and examine the team composition, seniority levels, availability of key specialists and which roles are included in the quoted price.
Depending on the project, these may include:
senior developers,
software architect,
QA specialists,
Project Manager or Delivery Manager,
DevOps engineers,
business analyst,
UX/UI designers.
Two proposals with a similar number of estimated hours may therefore represent very different delivery approaches. One may involve a more experienced team and greater participation from specialists responsible for quality and architecture, while the other may focus primarily on development.
The timeline is equally important. A shorter delivery schedule may require a larger team, but adding more people does not always accelerate a project proportionally. The more people working in parallel, the more important communication, coordination, clear responsibilities and dependencies between tasks become.
Question to ask the software house: Who will actually work on the project? Which roles are included in the price, who will be responsible for key decisions and what assumptions were used to establish the timeline?
In many projects, the biggest risks come from incorrect assumptions made at the beginning of the collaboration rather than from the technology itself. For more complex implementations, we therefore recommend starting with Discovery workshops. They allow us to validate business requirements, architecture and project scope before preparing the final estimate. If the client decides to proceed with Commerce Weavers after Discovery, we deduct the cost of the workshops from the implementation price. This makes Discovery an investment in better project preparation rather than an additional cost.
Don't compare the final prices alone. First, check whether the proposals cover the same scope: analysis and Discovery, development, integrations, data migration, testing, DevOps, project management, launch and post-launch maintenance.
You should also compare team composition, pricing models, timelines, estimation assumptions and any work explicitly excluded from the scope. Only then can you determine whether the quoted amounts actually refer to comparable projects.
Price differences do not necessarily come down to the hourly rates charged by different software houses.
One company may include analysis, architecture, QA, DevOps, migration and project management in its proposal, while another primarily estimates development work.
The assumptions, team composition and experience, scope of responsibility and pricing model may also differ. A lower initial price therefore does not always mean a lower total project cost.
A good estimate should explain how much the project will cost, what the client is paying for and which assumptions the amount is based on.
It should define the scope of work, team roles, pricing model, timeline, integrations, migration, testing, DevOps and the responsibilities of both parties.
It is equally important to identify what is excluded from the price and which circumstances could lead to budget changes.
There is no single pricing model that works best for every project.
Fixed Price can be a good choice when the scope is clearly defined and relatively stable. Time & Materials provides greater flexibility when requirements may evolve during the project.
In both cases, the key is to establish clear rules for managing scope, budget and changes. Neither pricing model eliminates the risks associated with incomplete or incorrect assumptions.
Yes. A lower initial price may reflect a narrower scope, omitted activities or different assumptions about responsibilities.
If data migration, testing, integrations, DevOps work or architectural changes turn out to be necessary during implementation, the actual project cost may increase.
This is why you should consider not only the implementation price, but also the potential costs of changes, maintenance and further platform development.
Choosing an e-commerce platform affects much more than the initial launch of an online store. It also influences future ...
Read more →
Choosing an e-commerce platform can start with a very long list of names competing on the market: Shopify, Adobe Commerc...
Read more →
More and more manufacturers, distributors and commerce companies are developing B2B and B2C sales in parallel. Business ...
Read more →
