Two proposals for the same store can differ by tens of per cent and both can make sense. It does not automatically mean that one supplier is expensive and the other is cheap. More often, they have priced two different outcomes.
One proposal stops when the code is written. Another includes discovery, UX, data migration, testing, launch and stabilisation. Until those responsibilities are separated, you are comparing totals rather than projects.
Why does the headline estimate mislead?
An early estimate is built on incomplete information. The problem is not that it may change; the problem is a document that hides the assumptions behind it. Before comparing suppliers, ask each one to price or explicitly exclude the same delivery areas.
When I estimate a project, I want to know where the data comes from, who makes each decision and how we will recognise a correct result. “ERP integration” may mean a basic order export or two-way synchronisation of stock, prices, customers, invoices and errors. It is one line in a brief but a completely different budget.
What belongs in an ecommerce development budget?
- Warranty and defects. Which defects are included, for how long and under what response rules?
- Acceptance feedback. Is correction of issues found during acceptance included or charged separately?
- Analysis and acceptance criteria. Who documents processes, user stories, exceptions and the definition of done?
- Extensions and modules. Does the proposal include selection, purchase, configuration, customisation and compatibility testing?
- Licences and subscriptions. Which costs recur monthly or annually?
- Project management and QA. Are planning, reviews, testing and risk reporting included?
- Integrations. Does the price cover both ends, data mapping, error handling and retries?
- UX and UI. Are you receiving a standard theme, an adaptation or a bespoke component system?
- Workshops and meetings. How much time is allocated to decisions, demonstrations and acceptance?
- Hosting and environments. Are development, test and production environments, backups and monitoring included?
- Training and documentation. Who prepares the client team to operate the store and its integrations?
If an item is missing, ask for one explicit label: “out of scope”, “client responsibility” or “priced after discovery”. Silence in a proposal does not make a cost disappear.
How should you compare proposals?
You do not need a procurement spreadsheet with a hundred columns. A simple table is enough: is the item included, who owns it and what is the acceptance result? Ask for a short clarification wherever the answer is vague.
- Scope: what will actually be delivered?
- Assumption: which data, decisions or services must the client provide?
- Exclusion: what has deliberately been left out?
- Acceptance: how will both sides decide that the item works?
- Recurring cost: which licence or subscription continues after launch?
Be careful with words such as “standard”. A standard checkout, migration or integration can mean something different to every supplier. If an area affects revenue or fulfilment, two precise sentences are worth more than a reassuring label.
What is the role of discovery?
Discovery should produce more than a general presentation. Its outputs should identify processes, integrations, data, roles, failure scenarios and architectural decisions. Only then can a fixed-price proposal or a meaningful Time & Materials cap be prepared.
For a complex Magento 2 programme, separating discovery from implementation is often valuable. Once the evidence is available, you can reduce the launch scope, phase integrations or change priorities without wasting development budget.
Good discovery does not document everything for the sake of it. It tackles the biggest uncertainties first: pricing processes, data quality, external system constraints and decisions that affect architecture. The rest can stay in a well-ordered backlog.
Which costs and tasks stay with the client?
The supplier’s budget does not automatically include the time of your internal team. Someone still needs to prepare data, approve UX, test business processes and explain how the ERP or warehouse actually behaves. If a decision waits for a week, the schedule waits too—even if the developers are ready.
Content, product images, policies, payment-provider agreements and changes on the ERP side also often remain with the client. Put those tasks into the same plan, give each one an owner and add a date. They are real project costs even when they never appear on the development invoice.
How should you plan contingency and post-launch cost?
Keep contingency for data quality, external API constraints and decisions discovered during testing. The right amount depends on uncertainty. A well-documented system with proven integrations needs less than a migration from software that nobody has touched in years.
Calculate the first year of operation separately: hosting, licences, monitoring, security fixes, platform updates and further development. Include a stabilisation period after launch, when unusual production data and peak traffic expose issues that were difficult to reproduce in a test environment.
A complete checklist cannot eliminate change. It gives both sides a shared language for responsibility and lets you compare genuinely equivalent proposals. That is much more useful than false precision in a single number on the first page of a PDF.
