Hiring ecommerce development goes wrong when both sides believe they are talking about the same thing and they are not. A commerce project has more moving parts than a two-page proposal suggests.
This guide covers the real phases, the deliverables worth demanding at each one, and what a serious quote is built from.
Phase 1: definition and architecture
Structure gets decided before design. Which categories exist, how products are filtered, what attributes each product carries, and what path someone follows when they arrive looking for something specific.
This phase also defines the purchase flow, the checkout process, and the shipping rules. Changing this after development is the most expensive form of rework there is.
Deliverables: sitemap, catalog structure, attribute definition, and a documented purchase flow.
Phase 2: interface design
The key templates get designed: home, category, product, cart, checkout, and content pages. Each one solves a different moment in the journey.
The product page deserves disproportionate attention. It is where the purchase is decided and where most projects invest less than they should.
Deliverables: mobile and desktop designs for each template, including error, loading, and empty-state views.
Phase 3: development and integrations
The store gets built, the platform configured, and external systems connected: payment gateway, invoicing, carriers, inventory, and measurement tools.
Every integration gets tested with real cases, not only sample data. A payment method that works in staging and fails in production is the worst possible launch scenario.
Deliverables: accessible staging environment, integration documentation, and a configuration log.
Phase 4: content loading
Uploading products with photos, descriptions, attributes, prices, and relationships. Operational work that consumes more hours than anyone estimates.
Define who does it from the start. If your team does, reserve real time; if the agency does, it must be quoted by SKU count.
Phase 5: testing and launch
Complete purchase tests across devices and browsers, validation of transactional emails, speed review, and verification of conversion tracking.
Deliverables: test report, signed launch checklist, and a redirect plan if this is a migration.
Phase 6: warranty and stabilization
The first thirty days reveal what testing did not. There must be a correction window at no cost for defects attributable to development.
What the quote must include
A complete proposal specifies, at minimum:
- Platform and version it is built on.
- Custom-designed templates, named individually.
- Number of products in the initial load.
- Integrations listed by provider.
- Revision rounds per deliverable.
- Analytics configuration and conversion events.
- Training and its duration.
- Post-launch warranty in days.
- Ownership of code, access, and editable files.
Whatever is not on that list will become an awkward conversation mid-project, usually once dates are already committed.
What gets quoted separately
Some line items legitimately sit outside development and should be budgeted from the start.
Product photography and video. Product page copywriting written with selling and search intent in mind. Brand identity work, if the brand is not resolved yet.
Monthly maintenance and traffic investment. And annual licenses for themes or plugins, renewed every twelve months.
An honest proposal mentions these even when it does not quote them, because they form part of the total cost of operating a store.
How the price is built
Development gets estimated in hours by role: project direction, design, front-end development, integration development, and testing.
A contingency margin of 15% to 25% is applied on top, because every project finds something unforeseen in the integrations.
When a quote arrives as a round number with no breakdown, ask for the structure. Not to negotiate margin, but to see whether anyone actually sized the work.
What the agency needs from you
Projects slip because of pending content far more often than because of development. Have this ready before kickoff.
The catalog in a spreadsheet with names, prices, attributes, and SKUs. The photos, or the decision to produce them and with whom.
Access to the domain, hosting, and measurement accounts. Tax details and the invoicing provider account.
Shipping, returns, and privacy policies, reviewed by whoever is responsible internally. And one person with authority to approve, available throughout the project.
That last point has the largest impact on the calendar. A project with three approvers and no clear hierarchy doubles its review cycles.
The mistakes that inflate a project
Four appear in nearly every rescue project we take on.
Starting design before catalog structure is settled. When a new attribute appears mid-design, approved templates get rebuilt.
Leaving measurement for the end. Analytics and conversion events get defined before development, because they change how the cart and checkout are built.
Approving designs on desktop only. Most traffic is mobile, and usability problems surface there once everything is already built.
Underestimating content. A technically finished store that cannot launch because half the catalog has no photos is a more common scene than it should be.
Migrations deserve their own plan
If you are replatforming rather than building new, the project carries a risk that greenfield builds do not: losing traffic you already earned.
Every existing URL needs a destination. That means a full crawl of the current site, a mapping document that pairs old addresses with new ones, and one-to-one 301 redirects implemented before launch rather than after.
Preserve the structure where you can. Changing platform and URL structure and navigation simultaneously makes it impossible to diagnose what caused a traffic drop.
Keep customer accounts, order history, and reviews. Reviews especially: they are an asset that took years to accumulate and most migrations quietly discard them.
And monitor daily for the first month. Indexing errors surface fast if someone is watching and silently compound if nobody is.
How to evaluate the provider
Ask to see two stores they built that have been running for at least a year. Not the launch: the sustained operation.
Ask who provides support after launch and with what committed response time. A vague answer means vague support.
Check whether they work with a staging environment and version control. A provider who edits directly in production will take your store down eventually.
And confirm the handover documentation includes access, configurations, and administration instructions. Without that, changing providers later becomes a project of its own.
At Conqr we start with that checklist in hand and a calendar with dates on both sides, not only ours.
Frequently asked questions
How long does a full project take?
Five weeks for a simple store to four months or more for one with complex integrations. The factor that stretches the timeline most is availability of content and approvals.
Can I launch in phases?
Yes, and it is usually advisable. Launching with core categories and part of the catalog lets you start selling and learning while the rest is completed.
What if I want changes mid-project?
They get handled as change requests, with their own hour estimate and calendar impact. A project without that mechanism ends in friction or runaway scope.
Do I need to migrate my existing content?
If you have a site with traffic, yes, with URL mapping and one-to-one redirects. Skipping that step is the most common cause of traffic collapse after a relaunch.
Who owns the code?
You do, if it is in the contract. Ask for it explicitly, along with editable design files and accounts registered under your company. Cost ranges by tier are in how much an ecommerce website costs.
Want us to review your project scope before you request quotes? Let’s talk.