Two ecommerce proposals can promise a new store and still cover very different projects. One may include a theme setup and a product import. Another may cover catalogue restructuring, integrations, search migration, content and launch support.
The headline price tells you very little until those differences are clear.
If you are planning a rebuild or a platform move, start by comparing what each proposal will deliver, what your own team must provide and what the store will cost to run. This guide gives you the questions to ask before you choose a delivery partner.
A useful brief explains why the project matters. “We need a better website” leaves too much room for interpretation.
Describe the problems you can see. Perhaps customers struggle to find compatible products. Your team may be copying orders between systems, or every campaign may need development work before it can go live.
For each problem, include the evidence you have and the outcome you want. That could be fewer product-related support questions, less manual order handling or an easier way to create campaign landing pages. Where you have a reliable baseline, include it.
Then ask each agency to explain why its proposed scope addresses those problems. A rebuild should have a clear purpose. Some issues may be better tackled through focused improvements to the existing store.
A list of page types is a useful starting point, but it does not tell you how the store will support buying decisions.
Ask how the proposal handles your important journeys. For example:
Check which templates are included, how many distinct layouts are needed and what happens when a product requires more information than the standard template allows.
Creative work belongs in this discussion too. Product photography, comparison graphics and clearer copy can help customers choose. Establish who is creating those assets, which products they cover and when they must be ready. Otherwise, an attractive design can arrive with an unresolved content job attached.
“Data migration included” needs more detail.
Ask for the record types and scope: products, variants, images, customers, orders, reviews, articles and any specialist information your operation relies on. Record what will not move, what needs cleaning and what will behave differently on the new platform.
The proposal should explain who supplies the data, who maps it and how representative records will be tested before the final transfer. Agree how exceptions will be recorded and signed off.
There is also a timing question: what happens to orders, stock changes and customer records created while the new store is being built? Ask how the final update will be handled, whether any trading restrictions are needed and who checks the result.
For a closer look at this part of the scope, see our data and platform migration service.
“Connect the warehouse” could describe a straightforward existing connector or a substantial custom development project.
List each system the store needs to work with. For each connection, ask:
Include exceptions as well as the ordinary order. Depending on your business, that might mean a partial fulfilment, cancelled order, refund or product with changing stock availability.
If an integration is still unproven, ask for a defined investigation before treating its cost and timing as settled. A visible uncertainty is easier to plan around than an assumption hidden inside a fixed launch date.
For an existing store, ask how the agency will identify important landing pages, plan changed URLs and check redirects. The proposal should also identify who checks indexing settings and monitors search performance after launch.
Google recommends mapping old URLs to their new destinations and monitoring a move. It also warns that rankings can fluctuate while a changed site is recrawled and reindexed. Treat a promise of completely unchanged rankings cautiously. Google Search Central guidance on site moves.
Measurement deserves its own line in the scope. Agree which purchases, enquiries and other relevant actions need recording, who is responsible for the setup and how it will be tested. Ask how consent settings will be carried through and validated with the person responsible for them.
Without that agreement, you could launch a different store and lose the ability to make a useful before-and-after comparison.
Ask to see the proposed acceptance criteria: the checks that must pass before the store goes live.
These should reflect your business, covering essential buying journeys, payment and delivery scenarios, data, integrations, tracking and the devices your customers use. Agree who tests, who approves and what happens if a critical issue remains open.
Accessibility should be part of the scope, with the intended standard and testing method made explicit. Keyboard access, form labels, clear instructions and useful error messages are important checks; they are not a substitute for a complete accessibility assessment. W3C guidance on initial accessibility checks.
Also ask about launch ownership. Who coordinates the changeover? What is the recovery plan if something important fails? Who is available afterwards, for how long, and which fixes are covered?
An agreed date matters. A shared definition of readiness matters just as much.
Put one-off delivery costs and recurring costs side by side. Ask each agency to identify:
Use the same comparison period and business assumptions for every proposal. Separate confirmed costs from estimates and usage-dependent charges.
Check ownership and access too. You should understand who controls the domain, platform account, analytics, subscriptions and any custom code, along with the licence and handover arrangements.
A proposal that costs less upfront may still be the right choice. The important thing is knowing what you are choosing and which responsibilities remain with your team.
Put the proposals into a simple comparison sheet. For each requirement, mark it as included, excluded, dependent on discovery or unclear. Add an owner and any recurring cost.
Send the unclear points back before making a decision. If the answers change the scope, ask for the proposal to be updated so the agreed version is the one you approve.
Choose the team whose approach fits your business, whose assumptions you understand and whose delivery plan you can work with. A clear proposal should make the difficult parts visible early.
WXLF brings ecommerce strategy, design, development and ongoing improvement together around the needs of your store.
To start a useful conversation, send us your current website, the main problem you want to solve, the systems the store needs to work with and any important deadline. If you have a working budget range, include it so we can discuss a realistic scope. Please do not send passwords or customer data through the enquiry form.
.svg)
.svg)
.svg)
.svg)
