What Is Included in an E-commerce Website Build?

When you commission an online store, the proposal usually arrives as a price and a list of pages. That list hides most of what you are really buying. The full set of ecommerce website build deliverables covers discovery documents, designs, a configured platform, clean product data, a working checkout, tax and shipping rules, integrations with the systems that run the business, a migration from the old store, analytics, testing records, and a handover that lets your team run the store without phoning the agency every week. Two quotes that look alike on the first page can differ widely in what they actually include.

This guide is for founders, e-commerce managers and marketing leads who are comparing proposals, and for anyone who has to explain to a finance team why two quotes for "the same store" are far apart. It sets out each group of deliverables: what it is, why it matters, when it happens in the project, what good looks like and what is often left out. It then covers how scope changes across price tiers, what reporting and handover should include, the contract terms worth checking, and a practical method for comparing proposals side by side.

A note on numbers. The price and timeline figures here are our own published starting rates and reviewed US market ranges. They are quoted as ranges because catalog size, integrations, migration and design scope move the real figure. Any worked example is illustrative and exists to show the arithmetic, not to describe a real client.

The short answer: ecommerce website build deliverables in a complete package

A complete build delivers a store that can take real orders from launch day, with the operational plumbing behind it, and the documentation and access your team needs to own it. If a proposal is silent on any item below, ask whether it is included, excluded or assumed to be your job. Silence is where most budget disputes start.

For a view of how these pieces translate into budget, our guide on how much an e-commerce website costs goes into price in more depth. The rest of this article works through each deliverable group in turn.

Discovery and platform choice

What it is

Discovery is the paid phase in which the supplier learns how your business actually sells and fulfills, then writes down what will be built. The deliverables are a requirements document, a platform recommendation with the reasons for it, an integration map showing every system the store must exchange data with, a migration inventory, and a refined estimate and schedule. In a typical project, discovery and platform choice take 2–4 weeks.

Why it matters

Almost every expensive surprise in an e-commerce project could have been found in discovery. Examples include a product type the platform cannot model cleanly, a checkout requirement the platform restricts, an ERP that exports inventory only once a night, or a set of old URLs that bring in most of your organic revenue. Finding these problems on paper costs a few meetings. Finding them during the build costs weeks.

What good looks like

A good platform recommendation compares at least two realistic options against your requirements. It names the trade-offs, including checkout restrictions, app dependencies, hosting responsibilities and the total cost of ownership over several years, not just the build. Our guide to choosing an e-commerce platform covers the criteria. A good integration map shows, for each system, which data moves in which direction, how often, what triggers it and what happens when it fails.

What is often missing

Proposals often skip discovery entirely and price the build from a sales call, then recover the gap through change requests. Another common gap is a platform recommendation that simply matches the supplier's favorite stack. If the discovery output does not include a revised estimate, you have paid for research without learning what it means for your budget.

Design deliverables

What it is

Design covers the templates a shopper actually moves through: home, category or collection, search results, product detail, cart, checkout (as far as the platform allows), account pages, and content pages such as guides, shipping information and returns. Each template should be designed for mobile and desktop. The design deliverable should also include a component library, meaning the buttons, product cards, form fields, badges, messages and navigation patterns the templates are built from. Design typically runs 3–6 weeks.

Why it matters

Product pages and the cart carry the revenue. A beautiful home page with a weak product template is a common and expensive mistake. The component library matters because your team will build new landing pages and campaigns for years after launch. Clear components let them do that without the store drifting into inconsistency.

What good looks like

Good design deliverables show real products, not placeholders: your longest product name, your product with the most variants, your worst photography, and an out-of-stock state. They cover the unglamorous states too, including empty cart, no search results, a product with no reviews, form errors and a failed payment. They specify how variant selection behaves, how price changes with options, and what the shopper sees when a combination is unavailable.

What is often missing

Mobile designs for every template, error and empty states, and accessibility annotations (focus order, labels, contrast) are the usual gaps. So is the distinction between a themed build and a custom front end. A themed build on a solid platform is a fraction of the design effort of a fully custom front end, and a proposal should say clearly which one you are buying.

Catalog and product data

What it is

This group covers the product data model (attributes, variants, options, bundles, pricing rules), the category or collection structure, filters, and the actual import of products, images and content. It overlaps with migration when products come from an old store, but it deserves its own line because it is often the most underestimated work in the project.

Why it matters

Catalog size and complexity is one of the biggest cost drivers. Two hundred simple products is not two hundred configurable ones with option-dependent pricing. The data model also determines what shoppers can filter on, what search can find, what feeds you can send to marketplaces and ad platforms, and how much manual work your team faces every time a product is added.

A worked example of catalog arithmetic

These numbers are illustrative. Suppose a brand has 200 products. 140 are simple products with no options. The other 60 each come in 3 colors and 4 sizes, which gives 12 variants per product. That is 60 × 12 = 720 variants, plus 140 simple products, for 860 sellable items in total, each needing a SKU, stock level, price and possibly its own image. If some option combinations change the price, for instance larger sizes costing more, the data model and the import both become more complex. A proposal that prices "200 products" without asking about variants has not really priced your catalog.

What good looks like

A good catalog deliverable includes a written data model, a spreadsheet template for adding products, rules for naming and image sizes, a filter set agreed with merchandising, and a validated import with a report of the records that failed and why. It also states who cleans the data. Cleaning is usually the client's job, but the supplier should specify the format they need.

What is often missing

Proposals often leave out the product content itself: descriptions, specifications, size guides and alt text for images. If you expect the supplier to write or rewrite product copy, it must be scoped explicitly. Also check whether product feeds for shopping ads and marketplaces are included, since they depend directly on the data model.

Checkout, payments, tax and shipping

What it is

This is the configuration that turns a browsing site into a store. It includes payment gateways and wallets, checkout layout and any customizations, discount and promotion rules, tax configuration, shipping zones and rates, carrier connections, delivery date messaging, order confirmation and transactional emails, and the rules for returns and refunds in the admin.

Why it matters

Checkout is where shoppers who have already decided to buy either complete the purchase or leave. Custom checkout is also a known cost trap. Some platforms restrict checkout customization, and working around that is expensive. It is worth knowing before you choose a platform, not after the designs are approved. Tax and shipping mistakes are costly as well: undercharging shipping erodes margin on every order, and wrong tax settings create liabilities that surface months later.

What good looks like

A good deliverable includes a written list of every payment method, shipping method and tax rule configured, with test orders proving each one works. That means domestic and international where relevant, discounted and full price, and each payment method. Address entry is a small detail that affects both conversion and delivery accuracy, and it deserves real attention. Good address forms use the right field order for each country, suggest addresses as the shopper types where it helps, and never block an order because a valid address fails an overly strict check. Transactional emails should be branded, accurate and tested, because they are the messages every customer actually reads.

What is often missing

Transactional email design, refund and partial refund testing, gift cards, and the tax treatment of shipping and discounts are frequently left out or assumed. Internationalization is a large scope item that often hides inside a single line. Currencies, taxes, languages, shipping rules and compliance per market each add work, so a proposal that says "multi-currency support" should explain which of those it actually covers.

Integrations with the systems that run the business

What it is

Integrations connect the store to ERP, inventory, fulfillment or third-party logistics, tax services, subscriptions, loyalty, email marketing, reviews, customer service tools and accounting. The deliverable is not only a working connection but a documented one: what data flows, in which direction, how often, what triggers it, and how failures are detected and handled. Build and integrations together typically take 6–16 weeks, and the width of that range comes largely from how many integrations there are and how cooperative the other systems are.

Why it matters

Each integration is another system with its own failure modes. An inventory sync that silently stops leads to overselling. An order export that fails on one unusual character leaves orders unshipped. When integrations break, the store can look fine from the front while the business behind it is quietly failing.

What good looks like

For each integration, look for a specification, a decision on whether to use an existing connector or custom code (with the reasons), error logging, alerting to a named person, a retry process and a test record covering failure cases as well as the happy path. When an off-the-shelf connector is used, the proposal should name it and say who pays its ongoing subscription.

What is often missing

Error handling and monitoring are the most common omissions, followed by the ongoing cost of connectors and apps. B2B requirements such as customer-specific pricing, quotes, purchase orders and account hierarchies often turn a simple ERP sync into a significant piece of work. Our article on B2B e-commerce explains why. If a proposal lists integrations only by name, with no data flows, the estimate behind it is a guess.

Migration, redirects and data

What it is

Migration moves products, customers, orders and URLs from the old platform to the new one. The deliverables are a migration plan, field mappings, trial imports, a final cutover import, a redirect map from every old URL of value to its new equivalent, and a verification report. Migration and data work typically takes 2–6 weeks and is usually underestimated.

Why it matters

Migration is often the largest single line in a replatforming budget. Customer accounts and order history matter for service and for repeat purchases. URLs matter because years of search rankings and inbound links point at the old addresses. A launch without a proper redirect map can wipe out organic traffic that took years to build.

What good looks like

Good migration work includes at least one full trial run before launch, with counts compared between old and new systems (products, variants, customers, orders) and a sample of records checked by hand. Here is an illustrative example of the redirect side. If an old store has 3,000 URLs, a sensible plan maps every product, category and content URL that received traffic or links to a specific new URL. Genuinely retired pages go to the closest relevant category rather than the home page. The plan should also say how customer passwords are handled, since many platforms cannot import them, and what message customers will see when they first log in.

What is often missing

Order history, customer password handling, image migration and the redirect map are the usual gaps. Also check the cutover plan: what happens to orders placed on the old store during the final migration, and who is responsible for freezing changes.

Analytics, performance and accessibility

What it is

These three deliverables are easy to promise and easy to skip. Analytics means e-commerce event tracking (product views, add to cart, checkout steps, purchases with correct revenue), conversion measurement for ad platforms, consent handling and a baseline report. Performance means agreed speed targets for key templates, tested on mobile. Accessibility means agreed conformance targets, usually WCAG at level AA, tested with keyboard and screen reader across the purchase path.

Why it matters

Without trustworthy analytics, you cannot tell whether the new store performs better than the old one, and every future optimization decision rests on guesswork. Slow product and category pages lose shoppers, especially on phones. Accessibility affects every customer who uses assistive technology and carries legal exposure for online stores.

What good looks like

A good analytics deliverable includes a tracking plan listing every event and its parameters, evidence that purchase revenue in analytics reconciles with the platform's order reports, and documentation your team can maintain. Our guide to e-commerce analytics setup sets out what to ask for. For performance, look for named targets and a test report on real templates with real product data. Our guide to e-commerce performance explains which measures matter. For accessibility, look for a test report covering the full path from search to order confirmation. Our practical guide to accessibility in e-commerce lists the common failures.

What is often missing

Revenue reconciliation, consent-aware tracking, performance testing after third-party apps and scripts are added, and accessibility testing of the checkout are the typical gaps. A statement that the site will be "fast and accessible" is not a deliverable. A target and a test report are.

Testing, launch, hypercare and handover

Testing and launch

Testing and launch typically take 2–4 weeks. The deliverables are a test plan, test orders covering every payment, shipping and tax case, cross-device and browser checks, integration tests including failure cases, a user acceptance testing period for your team, a launch checklist and a rollback plan. A sign-off record showing what was tested and what passed protects both sides.

The phase durations above are typical ranges for each stage. Because phases overlap and the ranges vary with scope, they should not simply be added together to predict a launch date. Our article on how long it takes to build an e-commerce store explains how schedules are really built. Ask each supplier for a schedule based on your own scope.

Hypercare

Hypercare is a defined period after launch during which the build team stays on call to fix defects quickly. The proposal should state how long it lasts, which response times apply, what counts as a defect rather than a change request, and what happens when it ends.

What handover should include

• Ownership: the store, domain, hosting, payment accounts, analytics properties, app subscriptions and code repository registered to your business, not the agency.
• Credentials: admin access for your team, with the agency's access reduced to what ongoing support requires.
• Documentation: how to add products, run promotions, edit content, handle refunds, and what each integration does and whom to call when it fails.
• Training: recorded sessions for the people who will run the store day to day.
• Technical notes: custom code, configuration decisions, known limitations and a list of every third-party app with its purpose and cost.
• Reports: the final test report, migration verification, performance and accessibility results and the analytics baseline.

Reporting during the project

During the build, expect a short regular status report covering progress against the schedule, decisions needed from you, risks, and budget used against budget remaining. Change requests should be written down with their cost and schedule impact before work starts, never billed afterward as a surprise.

How scope differs by package and price tier

E-commerce builds fall into recognizable tiers, and knowing which one you are buying makes proposals easier to read. The reviewed US market ranges are: a themed store on a hosted platform at $8,000 – $30,000, covering a customized theme, catalog setup, payments, shipping and basic integrations; a custom store build at $30,000 – $150,000, covering a bespoke front end, real integrations, migration and complex catalog logic; and conversion and optimization work at $2,000 – $10,000 per month for research, testing and incremental improvement of an existing store.

Our own published rates are starting prices, not guaranteed totals. A landing page or microsite starts from $4,800 per project, with a turnaround of 3–5 weeks. A marketing site starts from $18,000 per project, with a turnaround of 8–12 weeks, and its usual shape is a set of templates, real content, real integrations and a migration. Retained engineering starts from $145 per hour for a developer on your stack for an agreed share of each month, with a start within 2 weeks. The retained model suits stores that need steady improvement after launch rather than a single large project, and the hours agreed each month set the budget. Where a particular store sits against these figures depends on the cost drivers described above, and a quote for your scope turns that into one number.

The tier decision often comes down to platform. A growing brand weighing enterprise platforms should read our comparison of Adobe Commerce and Shopify Plus. Brands considering a decoupled, headless front end should weigh its flexibility against the extra build cost and the ongoing maintenance of two systems instead of one.

One-off versus recurring deliverables

Part of reading a proposal is knowing which deliverables happen once and which continue. Discovery, platform choice, the design system, the catalog data model, the migration and the redirect map are one-off pieces of work. If they are done well, you should not pay for them again until the next replatforming. Other deliverables recur. Product imports happen every season, promotions are set up every month, integrations need monitoring every day, and analytics needs checking whenever tracking or consent settings change. Performance and accessibility need retesting whenever new apps, scripts or templates are added.

A good proposal makes this split visible. It shows what the build fee buys once, what your team will do routinely with the documentation and training provided, and what ongoing support or optimization would cost if you want outside help. If the recurring work is not mentioned at all, the true cost of running the store is higher than the build price suggests. Also check whether the recurring work depends on the supplier, for example custom code only they understand, or whether your team or another developer could pick it up from the handover documents.

Contract terms to check before you sign

The statement of work and the contract decide what happens when things change, and in e-commerce projects things always change. Check these terms carefully.

• Scope definition: Does the statement of work list deliverables with enough detail to test against, such as templates, integrations with data flows, migration record types and redirect scope? A vague scope favors whoever interprets it.
• Assumptions and exclusions: Read these first. They show where the price is fragile, for example "client to supply clean product data" or "one payment gateway."
• Change control: How changes are requested, estimated and approved, and at what rate. Our retained engineering rate starts from $145 per hour, and a proposal should state the rate for changes in the same way.
• Payment milestones: Payments tied to accepted deliverables rather than to calendar dates.
• Acceptance: How long you have to test each deliverable, what counts as a defect and what happens if acceptance is disputed.
• Intellectual property and ownership: You should own the custom code, designs and content on full payment, with any licensed components listed.
• Accounts: Platform, hosting, domain, payment and analytics accounts created in your name.
• Warranty and hypercare: The length of the defect warranty after launch, and response times during it.
• Third-party costs: Platform subscriptions, apps, connectors and transaction fees, listed separately from the build fee.
• Termination: What you receive, and what you pay, if the project stops partway.

How to compare e-commerce build proposals

Proposals are hard to compare because each supplier describes the work differently. Put them into the same structure before comparing prices.

A comparison method

1. Normalize the scope. Map every proposal onto the same deliverable list. Price differences often vanish, or grow, once you see what each one leaves out.
2. Read the assumptions. Rank the proposals by how much risk they push back to you through assumptions such as clean data, a single gateway or no migration of order history.
3. Check the drivers. Confirm that each supplier has priced your actual catalog complexity, integrations, migration, checkout needs, markets and design scope. These are the factors that move cost.
4. Compare schedules phase by phase. Check that discovery, design, build and integrations, migration, and testing and launch each have realistic time allowed. Pay particular attention to migration, which is usually underestimated.
5. Test their thinking. Send your awkward orders and your integration map, and judge how specifically each supplier answers.
6. Check ownership and handover. Prefer the supplier who puts accounts, code and documentation in your hands.

Our list of questions to ask before hiring an e-commerce developer gives you the conversation to have alongside this comparison. For how we approach these projects ourselves, see our e-commerce development service page.