How Much Does an E-commerce Website Cost?

In the US market, a small e-commerce website typically costs $6,000 – $20,000, a store with custom templates, real integrations and a migration runs $20,000 – $75,000, and large or complex builds start at $75,000+. Our own published rates start at $4,800 per project for a landing page or microsite and $18,000 per project for a full multi-template site, with retained engineering from $145 per hour.

Those ranges are wide because "an online store" covers everything from a single-product launch page with a checkout button to a multi-language catalog wired into an ERP, a warehouse system and a B2B price list. The ecommerce website cost that matters to you depends on how many distinct page layouts the store needs, how ready your product content is, how many other systems the site has to talk to, and who is going to maintain it after launch.

This guide is for founders, e-commerce managers and marketing leads who need a realistic budget before they talk to suppliers. It explains the pricing models you will meet, sets market ranges next to our starting rates, walks through what moves the number, builds an illustrative budget from published rates only, and shows how to get a quote you can trust and how to plan spend beyond launch.

The short answer on ecommerce website cost

If you want one sentence to take into a budget meeting: most small and mid-sized online stores that are built properly land somewhere between the top of the small-site range and the middle of the business-site range, which means between $6,000 – $20,000 at the simple end and $20,000 – $75,000 once integrations and a migration are involved. Anything that is multi-language, deeply integrated, or where the store itself is the product sits in the $75,000+ band.

Three clarifications make that answer more useful:

• These are build costs. They cover discovery, design, development, testing and launch. They do not include your platform subscription, payment processing, paid apps or extensions, hosting for self-hosted platforms, product photography or copywriting unless the quote says so.
• They are per project, against a scope. A professional supplier prices a written scope with a named number of templates. If the scope is vague, the price is a guess, and guesses tend to grow.
• Our figures are starting prices. "From $18,000 per project" means that is where a marketing-site-shaped project begins with us, not what every store costs. A quote turns the range into one number for your catalog and your integrations.

The rest of this article explains how to find where your own store sits inside those ranges, and why two stores with the same number of products can differ in price several times over.

Pricing models and what each includes

Suppliers price e-commerce work in a handful of ways. Knowing which model you are being offered, and what it leaves out, matters more than the headline figure, because the same store can look cheap in one model and expensive in another while costing much the same in the end.

Fixed price per project

A fixed price works when the scope can be written down: how many templates, which integrations, how many products and pages to migrate, what accessibility standard, what browsers and devices. The supplier carries the risk of their own estimate being wrong; you carry the risk of changing your mind. For most store builds, this is the model that makes budgeting easiest, provided the scope is specific. If you want to understand how a supplier arrives at that number, the logic is much like any development estimate: counted templates, counted integrations, and an honest allowance for unknowns.

Retained engineering

A retainer buys an agreed amount of a developer's time each month. It suits stores that are already live and need a steady stream of improvements: new landing pages for campaigns, checkout fixes, app replacements, performance work, platform updates. It is a poor fit for a first build, because a build needs a fixed scope and an end date, not an open meter.

Time and materials

Useful when the problem is genuinely unknown, such as untangling an inherited custom platform. Ask for a cap, a weekly burn report and a stop point at which the scope is re-estimated. Without those, the model has no natural limit.

Theme packages

A configured theme on a hosted platform is a legitimate choice for a new store testing demand. The catch is that customizing a theme past its intended shape often costs more than building templates designed for your catalog in the first place. If you already know your product pages, filters or checkout need to behave differently from the theme's defaults, price the custom route too.

Market ranges against our published starting rates

The table below places the reviewed US market ranges next to our published starting rates. The comparison is not like for like in every row, because market ranges describe finished projects of a certain size and our figures are where a project of a given shape starts. Read it as a map of where your store is likely to sit.

Two things are worth noticing. First, a small store with a handful of templates can sit comfortably in the lower range, but the moment it needs a migration from an old platform or connections to inventory and fulfillment systems, it moves into the next band, even if the page count stays the same. Second, the jump from "small" to "with systems" is driven by integrations and data, not by design ambition.

What drives ecommerce website cost

Six factors account for most of the difference between two quotes for apparently similar stores. Understanding them lets you decide where to spend and where to simplify before you ask for a price.

Number of unique templates

A fifty-page site with six templates is a much smaller job than a twelve-page site with eleven. Count layouts, not pages. In a store, the typical templates are the homepage, a collection or category page, a product page, a cart, a search results page, a content page, and account pages. A catalog with five hundred products may still need only one product template, while a store selling configurable products, bundles and subscriptions might need three product templates that each behave differently. Our guides to product page design and faceted navigation and filtering show how much work sits inside the two templates that carry most of the revenue.

Content readiness

A site with copy and images ready moves at roughly twice the speed of one where content is written during the build. In e-commerce, "content" means product titles, descriptions, specifications, variant data, images for every variant, size guides, shipping and returns policies, and category copy. If your product data lives in spreadsheets with inconsistent column names, cleaning it is real work that someone has to do, and it is better priced up front than discovered in week six.

Integrations

A CRM, a booking system, a payment gateway, a legacy inventory feed. Each one is a separate contract with somebody else's API and somebody else's outage. Common store integrations include an ERP or inventory system, a warehouse or third-party logistics provider, an email and SMS platform, a reviews service, a tax calculation service, a search and merchandising tool, and an analytics and tag setup. Each integration needs mapping, error handling, testing with realistic data and a plan for what the store does when the other system is down. Planning measurement properly, as covered in a practical guide to e-commerce analytics setup, is itself an integration and should be scoped as one.

Accessibility target

Meeting WCAG 2.1 AA from the start adds modestly to design and build. Retrofitting it later costs several times more. For a store the hard parts are predictable: filter panels, variant selectors, carousels, modal carts, form validation at checkout and error messages. Our guide to accessibility in e-commerce goes through each of these. Put the target in the scope in writing so it is priced, not assumed.

Migration

Moving a thousand existing pages, preserving their URLs and their formatting, is its own project with its own risks. A store migration also moves products, variants, customer accounts, order history, reviews and redirects. The redirect map is what protects search traffic that took years to earn; it needs to cover products, categories, and any content pages that rank. A migration that keeps URLs stable where the new platform allows it is cheaper to test and safer to launch.

Who maintains it

Building something you can edit safely costs more up front than building something only we can change. It is almost always the cheaper of the two over three years. In a store, "edit safely" means your team can build a campaign landing page, reorder a collection, change a promotion banner or add a size guide without a developer and without breaking the layout. That capability is designed in, through well-structured content types and constrained components, and it is part of the price.

Platform choice, as a cost multiplier

Platform choice is not a separate price line in the market ranges above, but it changes all six drivers. A hosted platform keeps infrastructure off your plate and brings a large app ecosystem, at the cost of some flexibility. A headless architecture, where the storefront is built separately from the commerce engine, gives full design and performance control but adds templates, integrations and maintenance. Read choosing an e-commerce platform and a practical guide to headless commerce before you commit, because the choice is hard to reverse and it shapes every later quote.

Where the time goes: project phases and their costs

Cost follows time. The phases below are how a full store project typically runs with us. The durations are ranges, and the build phase varies most because it scales with template count.

The phase most owners underestimate is content and structure. It is where product data gets cleaned, categories get agreed and the store's information architecture is decided. Every week it slips pushes design and build back, and pushes the launch closer to a season you did not plan to launch in. Performance also belongs in the build rather than in a later cleanup; the reasons are covered in e-commerce performance: what actually works.

A worked budget example (illustrative)

This example is illustrative. The store, its scope and the hours are assumptions made up to show how a budget is built; the only prices used are our published starting rates, and a real quote would depend on your scope.

Picture a direct-to-consumer brand selling around two hundred products with color and size variants. It currently runs on an older platform, wants to move to a hosted platform, and needs connections to its inventory system, its email platform and a reviews service. It also plans a seasonal campaign each year that needs its own landing page. After launch, it wants a developer available for a set number of hours each month.

The team decides on the following for year one:

• A full multi-template store build, including a migration of products and URLs, priced from the marketing-site rate.
• One campaign microsite for a seasonal launch, priced from the landing-page rate.
• A retainer of 10 hours per month of engineering time for the twelve months after launch.

Some notes on reading this example. The build line is a floor: a store with three integrations and a migration will usually be quoted above the starting rate, and the quote will say by how much and why. The retainer line is arithmetic on a published hourly rate, so it moves directly with the hours you choose: halve the monthly hours and that line halves, double them and it doubles. None of the lines include the platform subscription, apps, payment processing or photography, which are paid to other parties or scoped separately.

It is also worth deciding, before the quote arrives, which lines could move to a later phase if the build comes back higher than planned. In this example, the campaign microsite could wait a season, and the retainer could start at fewer hours and grow once the team sees how much routine work the store generates. Deciding these trade-offs in advance keeps the negotiation about scope rather than about price alone.

Compare the build line with the market ranges. A store of this shape, with integrations and a migration, is squarely in the "business site with systems" band of $20,000 – $75,000 in the wider market. A starting rate below the bottom of that band does not mean the final number will be; it means the conversation starts there and the scope decides the rest.

A second, smaller illustration

A maker selling a single product line wants to test demand before committing to a full store. A landing page or microsite with a buy button, built accessible and fast on an editable CMS, starts at $4,800 per project with a 3–5 week turnaround. If demand is proven, the next step is the full build, and the microsite's content and design work carry forward. This is often the better first spend for a brand that is not yet sure what its catalog will look like in a year.

How to get an accurate quote

Most inaccurate quotes come from inaccurate briefs. A supplier can only price what they can see, and if the brief says "a store like our competitor's" the quote will be a guess padded for risk. The procedure below gets you a number you can hold a supplier to.

If you are selling to other businesses, add account structures, price lists and approval flows to the template and integration lists; B2B e-commerce brings requirements that change the scope substantially. Our e-commerce development page describes how we run discovery and what a written scope from us contains.

Red flags in cheap quotes

A low quote is not automatically a bad one; a small store with a handful of templates and no integrations can legitimately cost little. The problem is a low quote for a scope that is not small. These are the patterns to look for.

Each of these is a cost that has been moved rather than removed. It resurfaces as a change request, as lost search traffic after launch, as a store your team cannot edit, or as a rebuild two years early. When you compare quotes, compare them line by line against the same written scope, and ask each supplier to price the same exclusions so the totals mean the same thing.

Questions that expose a thin quote

• "Walk me through what happens when the inventory system is unavailable during checkout."
• "How many product templates have you allowed for, and what does each one handle?"
• "What does your redirect map cover, and who checks it after launch?"
• "How will my team add a new landing page without calling you?"
• "Which accessibility standard does your testing check against, and how?"

A supplier who has built stores like yours will answer these quickly and specifically. Vague answers are information too.

How to budget over time

The build is the largest single spend, but it is not the whole cost of owning a store. A realistic budget looks three years ahead, because that is roughly the horizon over which the decisions made in the build (platform, editability, integrations) either pay off or start to cost you.

Year one: build and stabilize

Year one carries the build, the migration and the period right after launch when real customers find the edge cases that testing missed. Keep some engineering time available for the first months after launch; a retainer from $145 per hour, starting within 2 weeks, is one way to do it without re-procuring a supplier. Use the first quarter to confirm analytics are recording correctly, so every later decision has data behind it.

Year two: improve what earns

Year two is where a store that was built to be edited pays back. Your team handles routine content changes; engineering time goes to improvements with measurable effects: faster pages, better filtering, a cleaner cart, fewer steps at checkout. Our pieces on cart page design and automated merchandising rules describe typical year-two work. Campaign microsites, from $4,800 per project, let marketing launch without touching the main store's templates.

Year three: review the foundations

By year three, check whether the platform and architecture still fit. Has the catalog grown past what the templates handle well? Have new channels, such as social selling or marketplaces, added integrations the original build did not plan for? Is a platform migration on the horizon? These are the decisions that turn into the next project, and they are cheaper to plan than to discover.

Recurring costs to budget alongside development

• Platform subscription and any paid apps or extensions, which scale with the features you use.
• Payment processing, charged by your payment provider.
• Hosting and a content delivery network, if you self-host or run a headless storefront.
• Third-party services connected to the store: email, reviews, search, tax, shipping.
• Content production: product photography, copy and video for new products.
• Periodic accessibility and performance reviews, especially after major changes.

None of these are priced in this article because they are set by other parties and vary with your volume. Get them from each provider and add them to your three-year plan next to the development spend.

Where to spend and where to save

With a fixed budget, the question is where money does the most work. The pattern across store builds is fairly consistent.

Spend on: the product page and collection templates, because that is where buying decisions happen; clean product data, because every template depends on it; integrations that remove manual work every day, such as inventory sync; accessibility from the start, because retrofitting it costs several times more; and editability, because it determines how much every future change costs.

Save on: bespoke homepage animation, which rarely changes buying behavior; a large number of one-off content templates that could share a flexible layout; custom features that a well-supported app already does reliably; and launching every integration on day one when some can wait for phase two.

One test helps with every borderline item: ask whether the store could take an order without it on launch day, and whether leaving it out would create manual work your team repeats every week. If the answer to the first is yes and the second is no, the item is a strong candidate for a later phase. If leaving it out means someone re-keys orders or stock levels by hand, it belongs in the first build, because that manual work has a cost of its own that never shows up on a quote.

Phasing is the most effective lever of all. Launch with the templates and integrations the store cannot trade without, then add the rest from a retainer once real customer data shows which additions matter. It keeps the first number lower, gets you trading sooner, and turns later spending into decisions backed by evidence. That approach keeps every stage of spending tied to what the store has actually shown it needs.